Re: Incubator structure
Hi Upayavira, -Original Message- From: Upayavira u...@odoko.co.uk Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, April 2, 2013 2:17 AM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) Chris, What I was trying to do with this particular thread is to identify the problems the incubator has before deciding on solutions. If we can get a common agreement on that, specific solutions will be much easier for us all to accept. No problem. I've articulated those for a while now, they were the original parts of my proposal [1]. See the headings there that being with: * Podlings are themselves distinct communities * Podlings are more and more able to pick up on the basic principles of the Incubator documentation; its legal oversight and its processes * Mentors encourage their podlings to operate autonomously These are a combination of observations (based on problems), and problems themselves, which have led to divergence in many of the core Incubator issues. The way I see it, many of the things that led me to write [1] still exist. And, many of the small steps that we took to unhinge some of the problems that were documented in [1] and the thread referenced in [1], such as Joe's experiment (to allow PPMC members VOTEs to matter more on releases), and such as steps that we've taken to reduce the requirement for 3 +1s from IPMC members to VOTE in a new PPMC member. Those are related to self governance, and the recognition that podlings themselves should not have to be so as dependent on folks from the IPMC, because it's a wild west. So, my question to you is are you able/willing to articulate the problems do you see the incubator as having, that need to be solved? That is, without (yet) suggesting how it should be fixed? Yes, I've articulated them for a while now. :) What I appreciated from Niall, and anyone that reads my proposal, are specific comments, backed with data, about the proposal itself. Sure it has a plan of action (as any good proposal should), but it has problems, and observations, that lead to that plan of action, too. I'd be very curious to hear how you see it. Thank you for kindly considering my opinion Upayavira. I respect and appreciate yours as well. Cheers, Chris [1] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Henry Saputra as new Incubator PMC member
Hi All, Please join me in welcoming Henry Saputra to the Incubator PMC. Henry, welcome! Please feel free to share a bit about yourself. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ANNOUNCE] David Nalley joins the Incubator PMC
Welcome David! Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Noah Slater nsla...@apache.org Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, April 2, 2013 10:34 AM To: general@incubator.apache.org general@incubator.apache.org Cc: David Nalley da...@gnsa.us Subject: [ANNOUNCE] David Nalley joins the Incubator PMC Dear community, I am pleased to announce that David Nalley joins the Incubator PMC. Please join me in extending a warm welcome to David! On behalf of the Incubator PMC, -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
A simple question for you all. If the current amount of podlings (38): [terra:~/tmp/podlings-content] mattmann% cat podlings.xml | grep current | wc -l 38 [terra:~/tmp/podlings-content] mattmann% Graduated over the next 3 months (~13 a month), or even the next 6 months (which is ~6 near the current rate +/- a few), would the Board members suddenly cease to function? And then in that time, if we gain 1-2 new projects a month (probably greater than the average the past few years), would the Board again cease to function? My proposal is to dissolve the self questioning, TL;DR, binding VOTEs and wild west that is the Incubator PMC. The rest of the situation stays the same. Keep the stinkin' documentation at http://incubation.apache.org, and folks can continue to work/crank on it there if they desire. Why is a (meta)/umbrella committee needed for this? And stop identifying the Board as the folks who shoulder the load. The committees (incoming and graduated) shoulder the load -- the Board only acts rarely, and when provoked. We also have committees for Legal and otherwise that can be leveraged here as I have stated. BTW, note the first step you all seem to agree on is also the first step in my proposal, that Greg and I proposed over a year ago. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Benson Margulies bimargul...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Tuesday, April 2, 2013 2:18 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) Ant is reflecting a real dilemma here. At Apache, we try to be egalitarian, and we try to work by consensus. The natural conclusion is that the many people needed to vote on releases are also part of the decision-making body for policy that controls those releases. The dilemma is that consensus doesn't always scale so well. Neither does supervision: when everyone is responsible, no one is responsible. There are several directions to go to on this. Chris M's proposal dissolves the IPMC into many, small, egalitarian communities, and leaves overarching policy for the board and comdev, where it lives for all the other projects. Ross' proposal sacrifices some egalitarianism to achieve better scaling of both decision-making and supervision. Ross' other proposal :-), to move documentation (and thus some/much of the locus of policy decision) making to comdev, reduces the load of decision-making that the IPMC has to find consensus on, and thus proposes to reduce the stress. I sense that Chris M finds my writing on his proposal frustrating. To try to do a better job of explaining myself: Chris proposes that this committee recommend its own demise to the board, to be replaced, in large part, by the board itself. Every board member who has been heard from so far has been less than enthusiastic. It's one thing for this community to self-govern, but self-destruction strikes me as outside of the mandate. It just strikes me as sideways to seek consensus inside a community that the community is incapable of reliable reaching consensus, amongst other things. If I believed that the IPMC was unfixably nonfunctional in supervision or decision-making, I wouldn't be seeking a consensus. I'd be reporting my view to the board, making a recommendation, and asking for direction. That's how I see my duty as an officer. In other words, if there's something functional to be the chair of, my job is to be the chair of it. If there's nothing functional to be the chair of, it's my job to say so, recognizing that the board might just disagree. Now that we've cleared up some other matters, I'll try to help us all discover if we have a consensus on one of these proposals. - 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: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Hi Niall, First off, thanks for reading my proposal! Specific comments below: -Original Message- From: Niall Pemberton niall.pember...@gmail.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Monday, April 1, 2013 7:00 AM To: general-incubator general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) On Mon, Apr 1, 2013 at 5:30 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Sunday, March 31, 2013 5:20 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus) On 31 March 2013 17:08, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Why is it so hard to see that the board is already watching those 22 nascent projects in the same manner they watch the 137 TLPs? Because they are not watching with the same manner. They are delegating a huge range of tasks such as IP oversight and mentoring to the IPMC. Yep this is the sticking point where we disagree -- b/c I disagree with that. 2 tasks are not a huge range. Also my table of responsibilities in the proposal [1] I believe clearly specifies where any responsibility is shifted and not one of them is the Board. There are two responsibilities you list that shift to the board - 1) spots problems with mentoring 2) fixes problems with mentoring. I agree, spots problems with mentoring could potentially fall on the board, if the incoming new project and its 3 ASF members don't spot the problem beforehand. Just like it falls to the the board related to all projects if there are issues (mentoring, the Apache Way or otherwise). Before I add that to my proposal, I would ask you to consider some of my recent emails related to mentoring issues with podlings, and ask that if you think that the IPMC is currently doing a great of spotting problems with mentoring. If you, if you can please cite examples that would be great. I have counter examples (Mesos, for one) wherein which emails requesting help have gone unanswered, but if you have others in support of that, I'd appreciate hearing them. Also in your proposal oversight of releases is discarded and therefore I would add spots problems with releases is also therefore ultimately the boards responsibility. My philosophy is that there can remain a small set of mentors, e.g., these shepherds if you will that ought to volunteer for projects as they come into the ASF and be part of their initial PMC. The initial Champion role should also be an ASF member, until the incoming project is ready to elect its own chair (should happen in 1 year). These same people are likely going to be the same people who are great at checking releases now (sebb, Marvin, others). There doesn't need to be an IPMC for them to do that. Jukka now Benson have IMO been successful in focusing podlings on what they need to do to graduate and pushing them through the process - rather than staying for years in the incubator. So I would add this to the list of what the board would need to pick up. Well sorry, I don't think it's Jukka and Benson. I've never been a shepherd once, neither has Chris Douglas, neither has a bunch of people that have successfully brought podlings through the Incubator as of late. Jukka and Benson aren't necessarily the only reasons that things shaped up around here though I wholly appreciate their efforts. Lastly I would also say that shifting voting on new projects from a public to private list is not an improvement and would exclude those proposing from answering any objections or concerns. Yes, I am +1 for that. In my proposal, I've gone and updated it to shift that responsibility to voting on general@incubator (which as I mention in my proposal will remain). One note I'd add -- in my proposal, responsibility is not directly shifted onto the board, until it's shown that the incoming project's committee is unable to handle it: (see shifted responsibility: The project's PMC. And if not, the project's VP. And if not that, the board or the membership. Just like the current way it works for existing TLPs. ) HTH. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA
Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Hi Benson,
-Original Message-
From: Benson Margulies bimargul...@gmail.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Sunday, March 31, 2013 8:02 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator structure (was Re: Vote on personal matters:
majority vote vs consensus)
[..snip..]
Chris M observes, if I may parody, that it's 'just like' the
discredited umbrella projects, and proposes to fix this by making
podlings even more like the standard model -- each one a TLP
supervised by The Board.
That's one part of it.
[..snip..]
I think that any alternative has to specifically address the alternate
legal structure. Who votes on releases? Who votes on karma? I
personally don't have a problem with a plan in which the incubator
isn't really a PMC at the end of the day. One way to combine Ross and
Chris is to say, 'well, the Board could decide that it can't watch 22
nascent projects, so it's delegated that to a committee.
Why is it so hard to see that the board is already watching those 22
nascent projects in the same manner they watch the 137 TLPs? And if they
are not then I call b. to the s. -- we ask the podlings to start operating
like TLPs on day 1 -- we ask the mentors to do the same -- and to teach
the PPMC that. Yet, the board isn't watching them in the same way?
Ross says the Board pays less attention to these (by implication) than
say the 137 TLPs at present. Ross is one Director. Good for him.
I know other directors (Greg IIRC at least) didn't want the Incubator
specific podling reports to go away (and to only have the summary
at the top of the Incubator report). That's at least one other Director
(there were probably more since there was consensus on the podling
specific reports not going away when it was discussed) that IMHO watches
the podlings the same way as the TLPs are watched.
And, why is it so hard to see that the Board may watch, but in the
end, it's on the specific committees ('podling' as we currently call
them or 'PPMC' or otherwise [TLP]) to manage their stuff? The Board
is the bazooka, the elephant gun, remember? That's why we're still
here discussing ad nauseum this topic a year later -- because to bazooka
the Incubator would be some monuments event, similar to the bazooka, of
PRC, etc. -- something that's discussed at ApacheCon over beer about the
'old ways' and 'can you believe when that happened, wow??!'. In the end,
it's not a monuments event. As Upayavira said, life went on in PRC, in
the sub committees; Apache went on.
What I've done is suggest [in the Apache vein], what is IMO, a logical,
incremental (and even potentially reversible) next step. Upayavira's
latest email on this was right -- he sees that the Incubator is broken,
and perhaps it needs to be split into smaller, separate committees. Ross
is right too -- maybe something else needs to be elected in the form of a
committee (his shepherds) to watch the incoming projects. My point is
-- great -- I can't see the forrest through the trees on the answer to
that
question yet. What i can see, and what I think even Upayavira and Ross
agree
with -- and you too Benson -- is that there is a grave problem here and it
needs' a fixin'. My deconstruction proposal does that.
I've suggested a logical next step to fixing it -- don't let the wacko
committee try and fix itself. That's like asking an insane asylum to
form a committee for how it will itself. Besides the insanity, they are
naturally in a conflict of interest state. Instead, I'm proposing, rubble
the asylum, transition delegation and authority if only temporarily until
some next step proposal can be agreed upon and discussed without the
inmates.
[..snip..]
Cheers,
Chris
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator structure (was Re: Vote on personal matters: majority vote vs consensus)
Hi Ross,
-Original Message-
From: Ross Gardler rgard...@opendirective.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Sunday, March 31, 2013 5:20 PM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator structure (was Re: Vote on personal matters:
majority vote vs consensus)
On 31 March 2013 17:08, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Why is it so hard to see that the board is already watching those 22
nascent projects in the same manner they watch the 137 TLPs?
Because they are not watching with the same manner. They are delegating a
huge range of tasks such as IP oversight and mentoring to the IPMC.
Yep this is the sticking point where we disagree -- b/c I disagree with
that.
2 tasks are not a huge range. Also my table of responsibilities in the
proposal [1]
I believe clearly specifies where any responsibility is shifted and not
one of
them is the Board. So I've enumerated at least the concerns of myself and
many others about
a range of tasks, and addressed them (for well over a year). I've heard
zero feedback
from you about what's wrong with my table, and what I've missed, what
could be improved
and have heard nothing but it's wrong (paraphrased) or it doesn't cover
all the tasks
that of course will get dropped on the Board? I've done the work to
document
my thoughts. You don't get to then just keep telling me it's wrong without
specifying
what precisely is wrong about it.
Ross says the Board pays less attention to these (by implication) than
say the 137 TLPs at present. Ross is one Director. Good for him.
I, personally, pay as much attention to the PPMCs as I do to TLPs. I'm
active in the IPMC and thus have more visibility. That doesn't mean they
should be expected to by me or by anyone else.
Actually it should be expected -- there is a reason that people like Jim
mentored AOO -- people like Sam joined in, and so did Greg with AOO and
Bloodhound (all 3 are directors). There is a reason that Bertrand has been
very active in the Incubator with Flex and other recent projects. Same as
Rich with Allura -- Roy helps a lot too with clarifications when needed.
I've seen more than a handful of emails from Brett Porter too, so he's
definitely around.
So, sorry Directors too pay just as much attention to PPMCs and to the
Incubator based on their
own individual Incubator and Director hats, and based on their reporting.
I know other directors (Greg IIRC at least) didn't want the Incubator
specific podling reports to go away (and to only have the summary
at the top of the Incubator report).
I don't think any of the Directors want them to go away. But board reports
are not what the IPMC is about. That is the reporting process within the
foundation and provides the level of oversight into the PPMCs that the
board requires. But the IPMC does *much* more than submit a monthly board
report with a verbatim copy of the podlings individual reports.
What i can see, and what I think even Upayavira and Ross
agree
with -- and you too Benson -- is that there is a grave problem here and
it
needs' a fixin'. My deconstruction proposal does that.
No, I do not agree there is a grave problem. I have denied that
repeatedly.
The IPMC has problems, but in the main it works extremely well.
Fine you don't think it's grave. I don't care how it's classified
('grave',
'purple', 'pink', 'yellow', whatever). There is a problem is what I
probably
should have said.
Look, I hear you that, it's probably possible that folks can come up with
even yet another layer beyond the Shepherds, etc., and that that can goad
people into thinking stuff is fixed around here. Jukka's work was great,
and
I applaud him for it, but as I said at the time, to me we're just adding
more
and more layers to the onion, instead of stripping it down to its roots and
core.
Also it's possible that if you guys continue to add layers, and suggest
mechanisms
for organizing those that are active around here, I may just go back to my
merry
way of getting podlings through the Incubator, graduated, and taught in
the ASF
way.
But it's also possible that the existence of this super/meta committee and
its
super awesome badges that many of the folks here are just too blind to
give them up
will wain on individuals.
[..snip..]
The first of these two roles is, for the most part, where the IPMC can
sometimes reach stagnation and can become extremely confusing to podlings
(getting multiple answers for one question for example). Maybe it is time
to move this to ComDev and take that area of conflict away from the IPMC.
This would leave the IPMC to focus on providing the oversight that Jukka's
new processes have started to heal and Benson is now fine-tuning.
I suggested this in my proposal -- and also creating
http://incubation.apache.org/
which is home to all the documentation/processes, etc. This is step #1
in my proposal BTW (moving to ComDev).
Also
Re: [VOTE] recommend Apache DeltaSpike for graduating out of the incubator
+1 (binding) from me.
Good luck!
Cheers,
Chris
++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++
-Original Message-
From: Mark Struberg strub...@yahoo.de
Reply-To: general@incubator.apache.org general@incubator.apache.org,
Mark Struberg strub...@yahoo.de
Date: Saturday, March 30, 2013 9:54 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: [VOTE] recommend Apache DeltaSpike for graduating out of the
incubator
Hi!
The Apache DeltaSpike podling is a project which contains common CDI
Extensions which are portable among many different Java EE containers and
even run on standalone CDI containers.
We are now incubating since December 2011 and believe we are ready for
graduation. We've shipped 3 releases and already see wide adoption in the
industry.
We've already done an internal VOTE on the proposal which passed with a
big majority [1].
The voices who raised concerns were mainly afraid of DeltaSpike not being
'finished' yet. But graduation doesn't mean that the product is final and
switches to maintenance, but that it is vital and there is an active
community around it. And this is certainly the case as shown by the 21
votes we got the last days.
Our status file [2] got updated recently and I consider the podling
namesearch task as completed [3].
Thus I'd like to ask the IPMC to VOTE on recommending the attached
graduation proposal to the board.
[+1] yes, go forward
[+0] meh, don't care
[-1] nope, because there's a blocker ${blocker_reason}
The VOTE is open for 72h
txs and LieGrue,
strub
[1] http://markmail.org/message/bmhr5woxidmgheco
[2] http://incubator.apache.org/projects/deltaspike.html
[3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-31
Proposed Board Resolution Report
X. Establish the Apache DeltaSpike 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 creating a set
of portable CDI (JSR-299) Extensions
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 DeltaSpike Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby is
responsible for the creation and maintenance of open-source
software related to creating a set of portable CDI Extensions;
and be it further
RESOLVED, that the office of Vice President, Apache DeltaSpike 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 DeltaSpike Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache DeltaSpike 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 DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir pmuir at redhat.com
Jason Porter lightguard.jp at gmail.com
Shane Bryzak sbryzak at gmail.com
Rudy de Busscher rdebusscher at apache.org
Christian Kaltepoth christian at kaltepoth.de
Arne Limburg arne.limburg at openknowledge.de
Charles Moulliard cmoulliard at gmail.com
Cody Lerum cody.lerum at gmail.com
Romain Mannu-Buccau rmannibucau at gmail.com
Matthew Jason Benson mbenson at apache.org
Jim Jagielski jim at apache.org
David Blevins dblevins at apache.org
Ken Finnigan ken at kenfinnigan.me
John D. Ament johndament at apache.org
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Struberg
be appointed to the office of Vice President, Apache DeltaSpike, 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 DeltaSpike 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 DeltaSpike Project; and be it further
RESOLVED, that the Apache DeltaSpike Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator DeltaSpike podling; and be it further
Incubator Deconstruction (was Vote on personal matters: majority vote vs consensus)
[Note subject line change for Benson] Hi Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, March 29, 2013 3:09 AM To: general general@incubator.apache.org Subject: Re: Vote on personal matters: majority vote vs consensus We clearly differ with our view if how much is delegated from board to IPMC. The amount of work the board does on x podlings weach month is less than the work they do on x TLPs. Yeah I guess this is the crux. I respect your opinion, but honestly feel strongly for my own too :) No worries, such is life. That is without the IPMC addressing issues that come up every now and again. We can go into detail if it becomes necessary. Well yeah that's the point. I've gone into details, ad nauseum. They are literally extrapolated on my proposal and in numerous email threads too. I've done the work to document them. There are problems of efficiency, that is what I believe is the problem. But as I said we need to agree to differ at this time. Without knowing the specifics, saying that we differ I don't think is Constructive at least on my end. IOW, I don't think it's anything that a bar camp, with some good IPA wouldn't solve ^_^ Where I differ from you is that not when each podling had 3 active and engaged mentors, all would be good in those cases. That is rarely the case though. Ross, if it's rarely the case, I wouldn't be here helping 6 podlings at the moment in the Incubator (and those podlings wouldn't have all come to me asking me directly to help mentor). I'm talking about 14 podlings over the last few years. Here you go I'll enumerate: ---graduated OODT Airavata SIS Gora Lucy Giraph cTAKES Any23 ---current HDT Mesos Tez Knox Climate Tajo Therefore your proposal means either a reduction in the number of accepted projects (problem: how do we know which to accept), a reduction in the quality of TLPs (problem: reduction in perceived quality of all ASF brands), or a bigger oversight role for the board (problem: will the board accept this?) The above is anecdotal -- the board has scaled from 90 projects a few years ago to 137 currently over that time. Based on that, I don't think any of the 3 above suggestions will happen. Cheers, Chris For me the first option is the only outcome that can be considered. If that is a desired change (it is not for me) then your proposal is great. For now though the change I want is a more efficient IPMC and this is why we need to agree to differ at least until more of the IPMC have a stomach for radical change. Ross Sent from a mobile device, please excuse mistakes and brevity On 29 Mar 2013 01:49, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Thursday, March 28, 2013 4:20 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Vote on personal matters: majority vote vs consensus I do not agree there is no IPMC oversight. The IPMC performs many actions each month which would fall to the board if the IPMC were disbanded. That is why the IPMC submits a board report. What specific actions would fall to the board in my proposal [1] outside of what the board already does for PMCs? I count a total of 0 in the right hand column of my table. Being specific myself: 1. Directors review the IPMC report, and are charged (at least the Director shepherd for the Incubator is; but so are other board members) with reviewing the podlings present in the Incubator report. There was discussion before about removing specific podling reports, and only leaving the summary -- this was nixed. Directors are still charged with reviewing podling individual reports, same as they are with actual project reports. Thus, if you say there are no more podlings, as I do in my proposal, please define, specifically, where the extra work is? 2. We always wax at the ASF about there being extremely little centralized authority. Oh, there's a problem? The board can't fix that -- it's a bazooka! Fix it yourself, PMC! OK, so with that said, what's the problem then by saying, no more podlings, there are simply PMCs? New projects come in to the ASF via steps 3-5 in my proposal -- through discussion on general@incubator that includes discussions of merit, community, etc, guided by the existing Incubator documentation. When a VOTE is ready, the board VOTEs on the incoming project(s). This is true today. Incubator podlings are *not officially endorsed projects of the ASF* until they are turned into TLPs by board resolution. Again, so what's changed? What's even more hilarious and illustrative of the guise towards decentralization is that there have been discussions within this very same thread that instead of telling the board
Re: Incubator Deconstruction (was Vote on personal matters: majority vote vs consensus)
Hahah, we all need sleep? What?!! :) Take care duder, we'll spent some cycles doing other emails while we let this sit. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, March 29, 2013 10:11 AM To: general general@incubator.apache.org Subject: Re: Incubator Deconstruction (was Vote on personal matters: majority vote vs consensus) Chris, The fundamental issue is that I don't agree the IPMC needs deconstructing. I believe it finds it difficult to come to a decision when unusual circumstance arises, but most of the time it does fine. I don't accept that using yourself as an example of how we can find sufficient mentors for all new entries is evidence that your proposal will scale and thus address the concerns I have expressed. You are not a typical mentor, most of us need sleep. I don't believe this topic needs debating as I don't believe the incubation process is broken. Your proposal doesn't actually solve the core problems of whether policy says this or that or whether best practice is this or that - which ultimately is the only thing the IPMC gets bogged down in. Your proposal simply moves all the hard parts to the membership and thus to the board. Moving problems does not solve them. Ross Sent from a mobile device, please excuse mistakes and brevity On 29 Mar 2013 16:51, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: [Note subject line change for Benson] Hi Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, March 29, 2013 3:09 AM To: general general@incubator.apache.org Subject: Re: Vote on personal matters: majority vote vs consensus We clearly differ with our view if how much is delegated from board to IPMC. The amount of work the board does on x podlings weach month is less than the work they do on x TLPs. Yeah I guess this is the crux. I respect your opinion, but honestly feel strongly for my own too :) No worries, such is life. That is without the IPMC addressing issues that come up every now and again. We can go into detail if it becomes necessary. Well yeah that's the point. I've gone into details, ad nauseum. They are literally extrapolated on my proposal and in numerous email threads too. I've done the work to document them. There are problems of efficiency, that is what I believe is the problem. But as I said we need to agree to differ at this time. Without knowing the specifics, saying that we differ I don't think is Constructive at least on my end. IOW, I don't think it's anything that a bar camp, with some good IPA wouldn't solve ^_^ Where I differ from you is that not when each podling had 3 active and engaged mentors, all would be good in those cases. That is rarely the case though. Ross, if it's rarely the case, I wouldn't be here helping 6 podlings at the moment in the Incubator (and those podlings wouldn't have all come to me asking me directly to help mentor). I'm talking about 14 podlings over the last few years. Here you go I'll enumerate: ---graduated OODT Airavata SIS Gora Lucy Giraph cTAKES Any23 ---current HDT Mesos Tez Knox Climate Tajo Therefore your proposal means either a reduction in the number of accepted projects (problem: how do we know which to accept), a reduction in the quality of TLPs (problem: reduction in perceived quality of all ASF brands), or a bigger oversight role for the board (problem: will the board accept this?) The above is anecdotal -- the board has scaled from 90 projects a few years ago to 137 currently over that time. Based on that, I don't think any of the 3 above suggestions will happen. Cheers, Chris For me the first option is the only outcome that can be considered. If that is a desired change (it is not for me) then your proposal is great. For now though the change I want is a more efficient IPMC and this is why we need to agree to differ at least until more of the IPMC have a stomach for radical change. Ross Sent from a mobile device, please excuse mistakes and brevity On 29 Mar 2013 01:49, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general
Re: Vote on personal matters: majority vote vs consensus
Hey Ross, I disagree. Chris' proposal removes the IPMC thus making the board legally responsible for everything that committee does today. Yes it replaces it with an oversight body, but how does that scale? Please let me respectfully disagree with your interpretation of my Incubator deconstruction proposal [1]. In fact, it does not make the board legally responsible in any different way than the board is currently responsible for its plethora of TLPs -- IOW, it doesn't change a thing. It basically suggests that incoming projects can simply fast track to (t)LPs from the get go, so long as they have = 3 ASF members present to help execute and manage the Incubator process which still exists in my proposed deconstruction. My point is that all the oversight currently provided by the IPMC would have to be provided by the board. We already know that having three mentors does not guarantee adequate support for podlings. I guess I would ask what oversight? There is no global IPMC oversight. Ever since Joe's experiment, and even before, the podlings that get through the Incubator (and I've taken quite a few now, and recently, so I think I can speak from a position of experience here within the last few years), are the ones that have active mentors and *distributed*, not *centralized* oversight. IOW, I'm not seeing any IPMC oversight at the moment. I'm seeing good mentors, located in each podling, distributed, that get podlings through. Those that stall well they need help. Usually the help is debated endlessly, and not solved, or simply solved with more active/better mentors. So, that's my whole point. You either agree with me that there is no IPMC oversight at the moment (for years now), and that really podlings are TLPs (well the ones that graduate within a fixed set of time as Sam was trying to measure before, or simply point out that is) or you still believe that there is oversight within the IPMC. I personally don't. That's why I wrote the proposal. And I think that's at least evident to me and more than a few others that that's the problem here and that's why I don't think the Incubator should exist anymore in its current form and should be deconstructed :) Thanks for your comments and conversation and for listening. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
Hi Dave, -Original Message- From: Dave Fisher dave2w...@comcast.net Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Thursday, March 28, 2013 3:38 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Vote on personal matters: majority vote vs consensus On Mar 28, 2013, at 9:19 AM, Mattmann, Chris A (388J) wrote: Hey Ross, I disagree. Chris' proposal removes the IPMC thus making the board legally responsible for everything that committee does today. Yes it replaces it with an oversight body, but how does that scale? Please let me respectfully disagree with your interpretation of my Incubator deconstruction proposal [1]. In fact, it does not make the board legally responsible in any different way than the board is currently responsible for its plethora of TLPs -- IOW, it doesn't change a thing. It basically suggests that incoming projects can simply fast track to (t)LPs from the get go, so long as they have = 3 ASF members present to help execute and manage the Incubator process which still exists in my proposed deconstruction. My point is that all the oversight currently provided by the IPMC would have to be provided by the board. We already know that having three mentors does not guarantee adequate support for podlings. I guess I would ask what oversight? There is no global IPMC oversight. Ever since Joe's experiment, and even before, the podlings that get through the Incubator (and I've taken quite a few now, and recently, so I think I can speak from a position of experience here within the last few years), are the ones that have active mentors and *distributed*, not *centralized* oversight. IOW, I'm not seeing any IPMC oversight at the moment. I'm seeing good mentors, located in each podling, distributed, that get podlings through. Those that stall well they need help. Usually the help is debated endlessly, and not solved, or simply solved with more active/better mentors. My experience as a shepherd shows that you can in fact recognize podling issues and eventually get them to the point where graduation of one kind or another happens. Two examples: EasyAnt graduating to Apache Ant. Etch finally graduated with a small, but sufficient PMC. I wasn't stating that you can't do this :) In fact, you are precisely the example of what I'm talking about when I say, 'good' mentors. You actively volunteered for a new system created by Jukka, to care about other podlings and sign off on their reports, and monitor them. Awesome sauce. Great job. OTOH, I've *never* volunteered to be a shepherd, b/c honestly I think it's an additional name/responsibility that's fairly meaningless. I've been signing off on other podling reports that I see for years. As have other mentors, Joe S used to do that -- Ant and Alex and others have done that too. Even before there was a name, 'shepherd' for this. So, that's my whole point. You either agree with me that there is no IPMC oversight at the moment (for years now), and that really podlings are TLPs (well the ones that graduate within a fixed set of time as Sam was trying to measure before, or simply point out that is) or you still believe that there is oversight within the IPMC. I don't think it is an either / or. The current amount of oversight for any podling is a function of mentors, current IPMC dynamics, and real life influences. The shepherds serve a purpose as more of a divining rod into that dynamic, many solutions are possible, and the podling needs to be pushed into making choices. Sure, I agree with that. And rather than generically stating there are choices, and we have many to choose amongst, I've actually written my thoughts down about a choice, a series of observations, a proposed solution and deconstruction of the Incubator. Cheers, Chris Regards, Dave I personally don't. That's why I wrote the proposal. And I think that's at least evident to me and more than a few others that that's the problem here and that's why I don't think the Incubator should exist anymore in its current form and should be deconstructed :) Thanks for your comments and conversation and for listening. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h
Re: Vote on personal matters: majority vote vs consensus
Hey Ross, -Original Message- From: Ross Gardler rgard...@opendirective.com Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Thursday, March 28, 2013 4:20 PM To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Vote on personal matters: majority vote vs consensus I do not agree there is no IPMC oversight. The IPMC performs many actions each month which would fall to the board if the IPMC were disbanded. That is why the IPMC submits a board report. What specific actions would fall to the board in my proposal [1] outside of what the board already does for PMCs? I count a total of 0 in the right hand column of my table. Being specific myself: 1. Directors review the IPMC report, and are charged (at least the Director shepherd for the Incubator is; but so are other board members) with reviewing the podlings present in the Incubator report. There was discussion before about removing specific podling reports, and only leaving the summary -- this was nixed. Directors are still charged with reviewing podling individual reports, same as they are with actual project reports. Thus, if you say there are no more podlings, as I do in my proposal, please define, specifically, where the extra work is? 2. We always wax at the ASF about there being extremely little centralized authority. Oh, there's a problem? The board can't fix that -- it's a bazooka! Fix it yourself, PMC! OK, so with that said, what's the problem then by saying, no more podlings, there are simply PMCs? New projects come in to the ASF via steps 3-5 in my proposal -- through discussion on general@incubator that includes discussions of merit, community, etc, guided by the existing Incubator documentation. When a VOTE is ready, the board VOTEs on the incoming project(s). This is true today. Incubator podlings are *not officially endorsed projects of the ASF* until they are turned into TLPs by board resolution. Again, so what's changed? What's even more hilarious and illustrative of the guise towards decentralization is that there have been discussions within this very same thread that instead of telling the board there are problems with the Incubator, that we should fix them ourselves here. Hehe. Kind of a reflexive but powerful look in the mirror about the desire to move *away* from centralization. Thus, I ask, why do we have a *centralized* (fake Board) IPMC if the goal of the ASF is for the PMCs to be self governing? The Apache way is intimated through tribal knowledge of its members. Activeness of a member (and 3 of them on a PMC) is something that the board is aware of, so these things will get caught at project creation, and/or through personnel additions incrementally. That being said, I think we ought to let this drop for now. Benson has stated he wants to address the specific problem that brought all this up again. For now lets agree to differ. No problem -- I think we're closer than it seems, but yes, I'm fine with dropping it. Cheers, Chris [1] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal Ross On 28 March 2013 16:19, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Ross, I disagree. Chris' proposal removes the IPMC thus making the board legally responsible for everything that committee does today. Yes it replaces it with an oversight body, but how does that scale? Please let me respectfully disagree with your interpretation of my Incubator deconstruction proposal [1]. In fact, it does not make the board legally responsible in any different way than the board is currently responsible for its plethora of TLPs -- IOW, it doesn't change a thing. It basically suggests that incoming projects can simply fast track to (t)LPs from the get go, so long as they have = 3 ASF members present to help execute and manage the Incubator process which still exists in my proposed deconstruction. My point is that all the oversight currently provided by the IPMC would have to be provided by the board. We already know that having three mentors does not guarantee adequate support for podlings. I guess I would ask what oversight? There is no global IPMC oversight. Ever since Joe's experiment, and even before, the podlings that get through the Incubator (and I've taken quite a few now, and recently, so I think I can speak from a position of experience here within the last few years), are the ones that have active mentors and *distributed*, not *centralized* oversight. IOW, I'm not seeing any IPMC oversight at the moment. I'm seeing good mentors, located in each podling, distributed, that get podlings through. Those that stall well they need help. Usually the help is debated endlessly, and not solved, or simply solved with more active/better mentors. So, that's my whole point. You either agree with me that there is no IPMC oversight at the moment (for years now), and that really podlings
Re: [VOTE] Graduate Apache Onami as TLD
+1 (binding). Good luck! Cheers, Chris On 3/26/13 12:04 AM, Christian Grobmeier grobme...@gmail.com wrote: Hi all, Apache Onami entered incubation before more than 3 months. Since then the community has proven to be pretty active and healthy. A few releases were made and the status page has been completed: http://incubator.apache.org/projects/onami.html Three new committers were added in the past weeks. SVNSearch shows, there is clearly one guy who is outstanding in his motivation, but others do commit as well: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Fonami Mailinglist Archives show the Community is discussing in public: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/ The community consists of new Apache-people and some more experienced Apache-people. I do not see any problem regarding developing the Apache-way. A [DISCUSS] thread on general@ showed no concerns. Simone Tripodi has been elected as the new Chair: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/% 3CCAPFNckisQo29Ssy6Q-WkKgAZLRa3VW%2B7afLCEbbVy6HsWX_rAg%40mail.gmail.com%3 E A resolution has been created and voted on: http://mail-archives.apache.org/mod_mbox/incubator-onami-dev/201303.mbox/% 3CCAPFNckjDujef_G6t1%3DjuTdOvuXsgxWq-%2BGntiOMdFpE%3DgwReDg%40mail.gmail.c om%3E The community vote for becoming a TLD was successful too: http://onami-dev.markmail.org/thread/6w2dvrs3bj755kdm We now kindly ask the IPMC to review our findings and vote on the Onami graduation. [ ] +1, yes propose the graduation of Apache Onami to the board [ ] -1, no, don't let Apache Onami graduate, because... Thanks, Christian -- 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
Re: Request for edit karma for incubator pages in http://wiki.apache.org/incubator
Fixed, you just surround the username with spaces with '[[' and with ']]'. Cheers, Chris On 3/13/13 4:41 PM, David Crossley cross...@apache.org wrote: Henry Saputra wrote: Hi, I would like to ask for karma to edit proposal for incubator project. In particular http://wiki.apache.org/incubator/MetaModelProposal My wiki user name is Henry Saputrahttp://wiki.apache.org/incubator/Henry%20Saputra Done. However i am not sure how to deal with spaces in usernames. http://wiki.apache.org/incubator/ContributorsGroup -David Thank you, Henry - 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 MRQL into the Incubator
+1 from me (binding). Good luck! Cheers, Chris On 3/6/13 9:04 AM, Leonidas Fegaras fega...@cse.uta.edu wrote: Dear ASF members, I would like to call for a VOTE for acceptance of MRQL into the Incubator. The vote will close on Monday March 11, 2013. [ ] +1 Accept MRQL into the Apache incubator [ ] +0 Don't care. [ ] -1 Don't accept MRQL into the incubator because... Full proposal is pasted below and the corresponding wiki is http://wiki.apache.org/incubator/MRQLProposal Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Sincerely, Leonidas Fegaras = Abstract = MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop and Hama. = Proposal = MRQL (pronounced ''miracle'') is a query processing and optimization system for large-scale, distributed data analysis. MRQL (the MapReduce Query Language) is an SQL-like query language for large-scale data analysis on a cluster of computers. The MRQL query processing system can evaluate MRQL queries in two modes: in MapReduce mode on top of Apache Hadoop or in Bulk Synchronous Parallel (BSP) mode on top of Apache Hama. The MRQL query language is powerful enough to express most common data analysis tasks over many forms of raw ''in-situ'' data, such as XML and JSON documents, binary files, and CSV documents. MRQL is more powerful than other current high-level MapReduce languages, such as Hive and PigLatin, since it can operate on more complex data and supports more powerful query constructs, thus eliminating the need for using explicit MapReduce code. With MRQL, users will be able to express complex data analysis tasks, such as PageRank, k-means clustering, matrix factorization, etc, using SQL-like queries exclusively, while the MRQL query processing system will be able to compile these queries to efficient Java code. = Background = The initial code was developed at the University of Texas of Arlington (UTA) by a research team, led by Leonidas Fegaras. The software was first released in May 2011. The original goal of this project was to build a query processing system that translates SQL-like data analysis queries to efficient workflows of MapReduce jobs. A design goal was to use HDFS as the physical storage layer, without any indexing, data partitioning, or data normalization, and to use Hadoop (without extensions) as the run-time engine. The motivation behind this work was to build a platform to test new ideas on query processing and optimization techniques applicable to the MapReduce framework. A year ago, MRQL was extended to run on Hama. The motivation for this extension was that Hadoop MapReduce jobs were required to read their input and write their output on HDFS. This simplifies reliability and fault tolerance but it imposes a high overhead to complex MapReduce workflows and graph algorithms, such as PageRank, which require repetitive jobs. In addition, Hadoop does not preserve data in memory across consecutive MapReduce jobs. This restriction requires to read data at every step, even when the data is constant. BSP, on the other hand, does not suffer from this restriction, and, under certain circumstances, allows complex repetitive algorithms to run entirely in the collective memory of a cluster. Thus, the goal was to be able to run the same MRQL queries in both modes, MapReduce and BSP, without modifying the queries: If there are enough resources available, and low latency and speed are more important than resilience, queries may run in BSP mode; otherwise, the same queries may run in MapReduce mode. BSP evaluation was found to be a good choice when fault tolerance is not critical, data (both input and intermediate) can fit in the cluster memory, and data processing requires complex/repetitive steps. The research results of this ongoing work have already been published in conferences (WebDB'11, EDBT'12, and DataCloud'12) and the authors have already received positive feedback from researchers in academia and industry who were attending these conferences. = Rationale = * MRQL will be the first general-purpose, SQL-like query language for data analysis based on BSP. Currently, many programmers prefer to code their MapReduce applications in a higher-level query language, rather than an algorithmic language. For instance, Pig is used for 60% of Yahoo MapReduce jobs, while Hive is used for 90% of Facebook MapReduce jobs. This, we believe, will also be the trend for BSP applications, because, even though, in principle, the BSP model is very simple to understand, it is hard to develop, optimize, and maintain non-trivial BSP applications coded in a general-purpose programming language. Currently, there is no widely acceptable declarative BSP query language, although there are a few special-purpose BSP systems for graph analysis, such as Google Pregel and Apache Giraph, for machine learning, such as BSML, and for scientific data analysis.
Re: [VOTE] Graduate Apache Bloodhound from Incubator
+1 from me (binding). Great job and good luck! Cheers, Chris On 3/9/13 4:31 PM, Gary Martin gary.mar...@wandisco.com wrote: Hi, Following the community graduation vote result announcement on the bloodhound-dev@i.a.o mailing list [1] and the conclusion of the podling name search [2], I would like to invite Apache Incubator to vote on recommending Apache Bloodhound for graduation. Please vote: [ ] +1 Graduate Apache Bloodhound podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Apache Bloodhound podling [ ] -1 Reject graduation of Apache Bloodhound podling from Apache Incubator because ... The vote will run for at least 72 hours. The proposed graduation resolution is below. Cheers, Gary [1] http://markmail.org/message/k6q7l4gvdtuhu6z2 [2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-22 --- X. Establish the Apache Bloodhound 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, for distribution at no charge to the public, related to a software development collaboration tool, including issue tracking, wiki and repository browsing. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bloodhound Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bloodhound Project be and hereby is responsible for the creation and maintenance of software related to a software development collaboration tool, including issue tracking, wiki and repository browsing; and be it further RESOLVED, that the office of Vice President, Apache Bloodhound 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 Bloodhound Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bloodhound 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 Bloodhound Project: * Mat Booth mbo...@apache.org * Matevž Bradač mat...@apache.org * John Chambers cham...@apache.org * Branko Čibej br...@apache.org * Joachim Dreimann jdreim...@apache.org * Andrej Golcov and...@apache.org * Peter Koželj pe...@apache.org * Gary Martin g...@apache.org * Gavin McDonald gmcdon...@apache.org * Ryan Ollos rjol...@apache.org * Mark Poole mpo...@apache.org * Greg Stein gst...@apache.org * Hyrum K. Wright hwri...@apache.org * Jure Žitnik j...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Gary Martin be appointed to the office of Vice President, Apache Bloodhound, 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 Bloodhound 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 Bloodhound Project; and be it further RESOLVED, that the Apache Bloodhound Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bloodhound podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bloodhound podling encumbered upon the Apache Incubator Project are hereafter discharged. - 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: [RESULT][VOTE] Release Apache Mesos 0.10.0-incubating (RC4)
[Dropping general@incubator.a.o] Great job, Ben and Mesos community! I see that Mesos 0.10 has synced to the mirrors: http://apache.claz.org/incubator/mesos/mesos-0.10.0-incubating/ Great news! Got any ideas about the [ANNOUNCE] email? Is there a template? See this example from the Apache OODT community: http://s.apache.org/gm We should also plan on updating the website. Great work! Cheers, Chris P.S. Saw that 0.11 RC is up now too! Great, but was wondering if there was a discussion of doing it and what should be included, etc., that you can point me to? On 3/6/13 11:42 AM, Benjamin Hindman benjamin.hind...@gmail.com wrote: The vote to release mesos-0.10.0-incubating has passed with 3 IPMC binding +1s and 3 non-binding +1s: IPMC binding votes: Chris Mattmann Paul Ramirez Andrew Hart Others: Vinod Kone Ben Mahler Ben Hindman Thank you! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Release Apache Mesos 0.10.0-incubating (RC4)
Sorry for the spam all. Long day. Cheers, Chris On 3/7/13 9:34 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: [Dropping general@incubator.a.o] Great job, Ben and Mesos community! I see that Mesos 0.10 has synced to the mirrors: http://apache.claz.org/incubator/mesos/mesos-0.10.0-incubating/ Great news! Got any ideas about the [ANNOUNCE] email? Is there a template? See this example from the Apache OODT community: http://s.apache.org/gm We should also plan on updating the website. Great work! Cheers, Chris P.S. Saw that 0.11 RC is up now too! Great, but was wondering if there was a discussion of doing it and what should be included, etc., that you can point me to? On 3/6/13 11:42 AM, Benjamin Hindman benjamin.hind...@gmail.com wrote: The vote to release mesos-0.10.0-incubating has passed with 3 IPMC binding +1s and 3 non-binding +1s: IPMC binding votes: Chris Mattmann Paul Ramirez Andrew Hart Others: Vinod Kone Ben Mahler Ben Hindman Thank you! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Curator into the Incubator
+1 binding. Cheers, Chris On 3/5/13 10:21 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Discussion has settled down so I am calling a VOTE for acceptance of Curator into the Apache Incubator. The vote will close at on Friday, March 8, 2013. [ ] +1 Accept Curator into the Apache incubator [ ] +0 Don't care. [ ] -1 Don't accept Curator into the incubator because... Full proposal is pasted below and the corresponding wiki is http://wiki.apache.org/incubator/CuratorProposal Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Sincerely, Jordan Zimmerman === PROPOSAL === Curator - ZooKeeper client wrapper and rich ZooKeeper framework Abstract Curator is a set of Java libraries that make using Apache ZooKeeper much easier. While ZooKeeper comes bundled with a Java client, using the client is non-trivial and error prone. Proposal Curator is a set of Java libraries that make using Apache ZooKeeper much easier. While ZooKeeper comes bundled with a Java client, using the client is non-trivial and error prone. It consists of three components that build on each other. Curator Client is a replacement for the bundled ZooKeeper class that takes care of some low-level housekeeping and provides some useful utilities. Curator Framework is a high-level API that greatly simplifies using ZooKeeper. It adds many features that build on ZooKeeper and handles the complexity of managing connections to the ZooKeeper cluster and retrying operations. Curator Recipes consists of implementations of some of the common ZooKeeper recipes. Additionally, Curator Test is included which includes utilities to help with unit testing ZooKeeper-based applications. Background Curator was initially developed by Netflix to make writing ZooKeeper-based applications easier and more reliable. Curator was open-sourced by Netflix on GitHub as an Apache 2.0 licensed project in July 2011. During this time Curator has been formally released many times and has gained widespread adoption. Rationale New users of ZooKeeper are surprised to learn that a significant amount of connection management must be done manually. For example, when the ZooKeeper client connects to the ensemble it must negotiate a new session, etc. This takes some time. If you use a ZooKeeper client API before the connection process has completed, ZooKeeper will throw an exception. These types of exceptions are referred to as recoverable errors. Curator automatically handles connection management, greatly simplifying client code. Instead of directly using the ZooKeeper APIs you use Curator APIs that internally check for connection completion and wrap each ZooKeeper API in a retry loop. Curator uses a retry mechanism to handle recoverable errors and automatically retry operations. The method of retry is customizable. Curator comes bundled with several implementations (ExponentialBackoffRetry, etc.) or custom implementations can be written. The ZooKeeper documentation describes many possible uses for ZooKeeper calling each a recipe. While the distribution comes bundled with a few implementations of these recipes, most ZooKeeper users will need to manually implement one or more of the recipes. Implementing a ZooKeeper recipe is not trivial. Besides the connection handling issues, there are numerous edge cases that are not well documented that must be considered. For example, many recipes require that an ephemeral-sequential node be created. New users of ZooKeeper will not know that there is an edge case in ephemeral-sequential node creation that requires you to put a special marker in the node¹s name so that you can search for the created node if an I/O failure occurs. This is but one of many edge cases that are not well documented but are handled by Curator. Current Status Meritocracy Curator was initially developed by Jordan Zimmerman in 2011 at Netflix. Developers external to Netflix provided feedback, suggested features and fixes and implemented extensions of Curator. Netflix's engineering team has since maintained the project and has been dedicated towards its improvement. Contributors to Curator include developers from multiple organizations around the world. Curator will be a meritocracy as it enters the Incubator and beyond. Community Curator is currently used by a number of organizations all over the world. Curator has an active and growing user and developer community with active participation in the http://groups.google.com/group/curator-users mailing list and at its GitHub home: https://github.com/Netflix/curator. Since open sourcing the project, there have been fifteen individuals from various organizations who have contributed code. Core Developers The core developers for Curator are: € Jordan Zimmerman € Jay Zarfoss Jordan has contributed towards Apache ZooKeeper and both Jordan and Jay are familiar with Apache principles and philosophy for community driven software development.
Re: [VOTE] Graduate cTAKES from Incubator
+1 binding. Great job great community great project. Cheers, Chris On 3/5/13 12:54 PM, Chen, Pei pei.c...@childrens.harvard.edu wrote: This is to open a VOTE to graduate Apache cTAKES podling from the Apache Incubator. Apache cTAKES entered the Incubator in June of 2012. We have made significant progress with the project since moving over to Apache. We currently have over 18 committers listed on our status page at [1] including over 10 which accepted after the podling was formed. A VOTE was also held on the ctakes-dev group with 12 +1 results for graduation [4]. During incubation, cTAKES has : * Produced 1 Release * Added over 10 new Committer/PPMC members and shows constant community activities * Cleared IP on code * Developed Roadmap(s) for the next major and minor releases in a community process and started working on that [2] * Established Apache cTAKES is a suitable name [3] * The community of Apache cTAKES is active, healthy, and growing and has demonstrated the ability to self-govern using accepted Apache practices. Please cast your votes: [ ] +1 Graduate Apache cTAKES podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Apache cTAKES podling [ ] -1 Reject graduation of Apache cTAKES podling from Apache Incubator because ... We'll run the vote for at least 72 hours. [1] http://people.apache.org/committers-by-project.html#ctakes [2] https://issues.apache.org/jira/browse/CTAKES#selectedTab=com.atlassian.jir a.plugin.system.project%3Aroadmap-panel [3] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-24 [4] http://markmail.org/search/+list:org.apache.incubator.ctakes-dev#query:%20 list%3Aorg.apache.incubator.ctakes-dev+page:1+mid:y5lxfqrp2tgzbuwq+state:r esults Resolution: --- X. Establish the Apache cTAKES 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, for distribution at no charge to the public, related to the processing of natural language text from the electronic medical record. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache cTAKES Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache cTAKES Project be and hereby is responsible for the creation and maintenance of software related to the processing of natural language text from the electronic medical record; and be it further RESOLVED, that the office of Vice President, Apache cTAKES 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 cTAKES Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache cTAKES 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 cTAKES Project: Andy McMurry and...@apache.org Britt Fitch brittfi...@apache.org Chen Lin c...@apache.org Chris Mattmann mattm...@apache.org Ding Cheng Li leonlee...@apache.org Dmitriy Dligach dlig...@apache.org Grant Ingersoll gsing...@apache.org Guergana K. Savova gsav...@apache.org Hongfang Liu liuhongf...@apache.org James J Masanz james-mas...@apache.org Jörn Kottmann jo...@apache.org Kim Ebert Matt Coarr mattco...@apache.org Karthik Sarma ksa...@apache.org Pei J Chen chen...@apache.org Scott Russell Halgrim shalg...@apache.org Sean Finan seanfi...@apache.org Sean Patrick Murphy spmurph...@apache.org Siddhartha Jonnalagadda siddhar...@apache.org Stephen Wu s...@apache.org Steven Bethard stevenbeth...@apache.org Sunghwan Sohn ss...@apache.org Tim Miller tm...@apache.org Troy C. Bleeker blee...@apache.org Vinod C Kaggal vkag...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Pei J Chen be appointed to the office of Vice President, Apache cTAKES, 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 cTAKES 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 cTAKES Project; and be it further RESOLVED, that the Apache cTAKES Project be and hereby is tasked with the migration and rationalization of the Apache Incubator cTAKES podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator cTAKES podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands,
Re: Would you please give me a write access to http://wiki.apache.org/incubator ?
Thanks Daniel, I made it a link using '[[' and ']]'. Thanks! Cheers, Chris On 2/27/13 3:40 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: I think you need to edit ContributorsGroup to make the [[username a link]] Mattmann, Chris A (388J) wrote on Wed, Feb 27, 2013 at 23:06:44 +: Hi there Joe, I went ahead and granted karma. Please let me know if it works. It might not since there are spaces in your wiki username, so if it doesn't work let me know. Cheers, Chris On 2/27/13 3:04 PM, H. Joe Lee hyok...@hdfgroup.org wrote: Hi, I'd like to work on an incubation proposal through wiki. Would you please give me a write access? My wiki user name is H. Joe Lee. Thanks, -- HDF: Software that Powers Science - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Tajo into the Apache Incubator
+1 (binding) from me. Cheers, Chris On 2/28/13 10:11 AM, Hyunsik Choi hyun...@apache.org wrote: Hi Folks, I'd like to call a VOTE for acceptance of Tajo into the Apache incubator. The vote will close on Mar 7 at 6:00 PM (PST). [] +1 Accept Tajo into the Apache incubator [] +0 Don't care. [] -1 Don't accept Tajo into the incubator because... Full proposal is pasted at the bottom on this email, and the corresponding wiki is http://wiki.apache.org/incubator/TajoProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Hyunsik PS: From the initial discussion, the main changes are that I've added 4 new committers. Also, I've revised some description of Known Risks because the initial committers have been diverse. Tajo Proposal = Abstract = Tajo is a distributed data warehouse system for Hadoop. = Proposal = Tajo is a relational and distributed data warehouse system for Hadoop. Tajo is designed for low-latency and scalable ad-hoc queries, online aggregation and ETL on large-data sets by leveraging advanced database techniques. It supports SQL standards. Tajo is inspired by Dryad, MapReduce, Dremel, Scope, and parallel databases. Tajo uses HDFS as a primary storage layer, and it has its own query engine which allows direct control of distributed execution and data flow. As a result, Tajo has a variety of query evaluation strategies and more optimization opportunities. In addition, Tajo will have a native columnar execution and and its optimizer. Tajo will be an alternative choice to Hive/Pig on the top of MapReduce. = Background = Big data analysis has gained much attention in the industrial. Open source communities have proposed scalable and distributed solutions for ad-hoc queries on big data. However, there is still room for improvement. Markets need more faster and efficient solutions. Recently, some alternatives (e.g., Cloudera's Impala and Amazon Redshift) have come out. = Rationale = There are a variety of open source distributed execution engines (e.g., hive, and pig) running on the top of MapReduce. They are limited by MR framework. They cannot directly control distributed execution and data flow, and they just use MR framework. So, they have limited query evaluation strategies and optimization opportunities. It is hard for them to be optimized for a certain type of data processing. = Initial Goals = The initial goal is to write more documents to describe Tajo's internal. It will be helpful to recruit more committers and to build a solid community. Then, we will make milestones for short/long term plans. = Current Status = Tajo is in the alpha stage. Users can execute usual SQL queries (e.g., selection, projection, group-by, join, union and sort) except for nested queries. Tajo provides various row/column storage formats, such as CSV, RowFile (a row-store file we have implemented), RCFile, and Trevni, and it also has a rudimentary ETL feature to transform one data format to another data format. In addition, Tajo provides hash and range repartitions. By using both repartition methods, Tajo processes aggregation, join, and sort queries over a number of cluster nodes. To evaluate the performance, we have carried out benchmark test using TPC-H 1TB on 32 cluster nodes. == Meritocracy == We will discuss the milestone and the future plan in an open forum. We plan to encourage an environment that supports a meritocracy. The contributors will have different privileges according to their contributions. == Community == Big data analysis has gained attention from open source communities, industrial and academic areas. Some projects related to Hadoop already have very large and active communities. We expect that Tajo also will establish an active community. Since Tajo already works for some features and is in the alpha stage, it will attract a large community soon. == Core Developers == Core developers are a diverse group of developers, many of which are very experienced in open source and the Apache Hadoop ecosystem. * Eli Reisman ereisman AT apache DOT org * Henry Saputra hsaputra AT apache DOT org * Hyunsik Choi hyunsik AT apache DOT org * Jae Hwa Jung jhjung AT gruter DOT com * Jihoon Son ghoonson AT gmail DOT com * Jin Ho Kim jhkim AT gruter DOT com * Roshan Sumbaly rsumbaly AT gmail DOT com * Sangwook Kim swkim AT inervit DOT com * Yi A Liu yi DOT a DOT liu AT intel DOT com == Alignment == Tajo employs Apache Hadoop Yarn as a resource management platform for large clusters. It uses HDFS as a primary storage layer. It already supports Hadoop-related data formats (RCFile, Trevni) and will support ORC file. In addition, we have a plan to integrate Tajo with other products of Hadoop ecosystem. Tajo's modules are well organized, and these modules can also be used for other projects. = Known Risks = == Orphaned Products == Most of codes have been developed by only two core
Re: [VOTE] Release Apache Mesos 0.10.0-incubating (RC4)
Great. We just need 1 more IPMC +1 here. Anyone willing to contribute a review of Mesos 0.10.0-incubating RC4? Cheers, Chris On 3/4/13 9:57 AM, Benjamin Hindman b...@eecs.berkeley.edu wrote: Yes, my vote is a +1. On Sat, Mar 2, 2013 at 4:40 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Ben, just FYI on this, is your VOTE +1? The current tally I have is: +1 Chris Mattmann* * - IPMC We need probably a couple VOTEs from the Mesos community here (PPMC members), can you poke Vinod, as well as anyone else that has time to build and test and review the RC? IPMC folks -- a review and a couple more binding VOTEs would really help out Mesos here. Can folks try it out and VOTE? Thank you. Cheers, Chris Vote Wrangler Mattmann On 2/7/13 10:32 PM, Benjamin Hindman b...@berkeley.edu wrote: Please vote on releasing the following candidate as Apache Mesos (incubating) version 0.10.0. This will be the second incubator release for Mesos in Apache. -- --- Changes since last release candidate: * Updated configure.ac to work better on OS X 10.8. * Added missing license (the only blocker on the previous candidate). -- --- The candidate for Mesos 0.10.0-incubating release is available at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-i n cubating.tar.gz The tag to be voted on: https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.10.0-incu b ating-RC4 The MD5 checksum of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-i n cubating.tar.gz.md5 The signature of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-i n cubating.tar.gz.asc Mesos' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS Please vote on releasing this package as Apache Mesos 0.10.0-incubating! The vote is open until Monday, February 11th at 5:00 pm (PST) and passes if a majority of at least 3 +1 IPMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.10.0-incubating [ ] -1 Do not release this package because ... To learn more about Apache Mesos, please see http://www.mesosproject.org. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ripple, Streams, Onami, HDT need to fix your metadata
Hi David, I'll fix HDT's. Cheers, Chris On 3/4/13 11:15 PM, David Crossley cross...@apache.org wrote: Ripple, Streams, Onami, Hadoop Development Tools ... Those projects would have received the email reminder about reporting. You need to care for your podling metadata in the content/podlings.xml file to take yourself off the monthly schedule and onto quarterly. (Unless you do want to keep doing monthly.) See column C and the help notes below the table: http://incubator.apache.org/clutch.html This file http://incubator.apache.org/report-groups.txt and http://incubator.apache.org/report_due_3.txt are generated from that content/podlings.xml file and are used to automate the reminders and other stuff. -David David Crossley wrote: Dave Fisher wrote: Hey Folks, Etch has graduated and is now a TLP, correct? It's board reports should now go directly to board@ from the PMC chair. As explained in the Incubator graduation docs, the Etch project needs to finalise their graduation steps. http://incubator.apache.org/clutch.html#etch http://incubator.apache.org/clutch.html#other http://incubator.apache.org/clutch.html#h-Graduate -David Regards, Dave Begin forwarded message: From: Marvin no-re...@apache.org Date: March 4, 2013 4:18:48 AM PST To: d...@etch.incubator.apache.org Subject: Incubator PMC/Board report for Mar 2013 ([ppmc]) Reply-To: d...@etch.apache.org delivered-to: mailing list d...@etch.apache.org delivered-to: moderator for d...@etch.apache.org Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 March 2013, 10:30:00:00 PST. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, Mar 6th). Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/March2013 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Curator for the Apache Incubator
Hi Jordan, Yep, thank you. I will be suggesting at graduation time barring any epiphanies all around that you guys go the TLP route. Good luck. Cheers, Chris On 3/1/13 6:29 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Chris, I added a line to the Alignment section. Let me know if it's OK. -JZ On Feb 26, 2013, at 1:23 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: I would appreciate at some level a note in your proposal regarding at least the concern by one member of the IPMC that Curator should grow into its own TLP rather than be a part of ZK should it be accepted. - 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 Provisionr into the Apache Incubator
+1 from me (binding). G'luck! Cheers, Chris On 3/2/13 3:35 PM, Andrei Savu as...@apache.org wrote: Hi Guys, I'd like to call a VOTE for acceptance of Provisionr into the Apache Incubator. The vote will close on March 8. [] +1 Accept Provisionr into the Apache incubator [] +0 Don't care. [] -1 Don't accept Provisionr into the incubator because... Full proposal is pasted at the bottom on this email, and the corresponding wiki is http://wiki.apache.org/incubator/ProvisionrProposal Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Andrei Savu -- Provisionr Proposal == Abstract == Provisionr is an effort to develop a service that can be used to create and manage pools of virtual machines on multiple clouds. Our focus is on semi-automated workflows and cloud portability. == Proposal == Provisionr solves the problem of cloud portability by hiding completely the APIs and only focusing on building a cluster that matches the same set of assumptions on all clouds, assumptions like: running a specific operating system (e.g. Ubuntu 12.04 LTS), having the same set of pre-installed packages and binaries, sane dns settings (forward reverse ip resolution - as needed for Hadoop), ntp settings, networking settings, firewall, ssh admin access, vpn access etc. As a secondary goal Provisionr should also provide primitives for building automatic or semi-automatic workflows for configuring services, workflows that assume that all the machines share a common set of characteristics as described above. == Background == Creating clusters on cloud infrastructure is non-trivial because careful orchestration is required. To make it easy to deploy services we need to start from a foundation that matches a common set of assumptions on multiple providers. == Rationale == This project started as a re-write of the core of Apache Whirr but has a different target being more focused on semi-automated workflows and cloud portability. == Initial Goals == * Build a community * Provide an excellent user experience for semi-automatic workflows (e.g. using Rundeck) * Implement a REST service and a Web Console * Add support for more providers == Current Status == Provisionr had four releases on [[ https://github.com/axemblr/axemblr-provisionr/wiki|GitHub]] and it's used to deploy Hadoop clusters on-demand at Axemblr and infrastructure for testing / QA. === 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 community interested in cloud service infrastructure is currently spread across many smaller projects, and one of the main goals of this project is to build a vibrant community to share best practices and build common infrastructure. === Core developers === Core developers are very experienced in the Apache ecosystem. To achieve more diversity of developers, we will be eager to recruit developers from diverse companies. * Andrei Savu - asavu at apache dot org (Apache Whirr PMC) * Ioan Eugen Stan - ieugen at apache dot org (Apache James PMC) * Alex Ciminian - alex.ciminian at gmail dot org === Alignment === Provisionr complements Apache Whirr and later on it should provide a robust foundation for more advanced functionalities. == Known Risks == === Orphaned products === The contributors have significant open source experience and the project is being used as part of a commercial product, so the risk of being orphaned is relatively low. We plan to mitigate this risk by recruiting additional committers. === Inexperience with Open Source === Most of the initial committers have experience working on open source projects. Andrei Savu and Ioan Eugen Stan have experience as committers and PMC members on other Apache projects. === Homogenous Developers === We are committed to recruiting additional committers from other companies based on their contributions to the project. === Reliance on Salaried Developers === It is expected that Provisionr development will occur on both salaried time and on volunteer time, after hours. The majority of initial committers are paid by their employer to contribute to this project. However, they are all passionate about the project, and we are confident that the project will continue even if no salaried developers contribute to the project. We are committed to recruiting additional committers including non-salaried developers. === Relationships with Other Apache Products === Provisionr is closely integrated with CloudStack, Karaf, CXF, BigTop in a numerous ways. We look forward to collaborating with those communities, as well as other Apache communities (like Apache Helix). === A
Re: [VOTE] Release Apache Mesos 0.10.0-incubating (RC4)
Ben, just FYI on this, is your VOTE +1? The current tally I have is: +1 Chris Mattmann* * - IPMC We need probably a couple VOTEs from the Mesos community here (PPMC members), can you poke Vinod, as well as anyone else that has time to build and test and review the RC? IPMC folks -- a review and a couple more binding VOTEs would really help out Mesos here. Can folks try it out and VOTE? Thank you. Cheers, Chris Vote Wrangler Mattmann On 2/7/13 10:32 PM, Benjamin Hindman b...@berkeley.edu wrote: Please vote on releasing the following candidate as Apache Mesos (incubating) version 0.10.0. This will be the second incubator release for Mesos in Apache. -- --- Changes since last release candidate: * Updated configure.ac to work better on OS X 10.8. * Added missing license (the only blocker on the previous candidate). -- --- The candidate for Mesos 0.10.0-incubating release is available at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz The tag to be voted on: https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.10.0-incub ating-RC4 The MD5 checksum of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz.md5 The signature of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz.asc Mesos' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS Please vote on releasing this package as Apache Mesos 0.10.0-incubating! The vote is open until Monday, February 11th at 5:00 pm (PST) and passes if a majority of at least 3 +1 IPMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.10.0-incubating [ ] -1 Do not release this package because ... To learn more about Apache Mesos, please see http://www.mesosproject.org. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] MRQL for the Apache Incubator
Sounds awesome guys look forward to the VOTE. Cheers, Chris On 3/2/13 7:12 AM, Leonidas Fegaras fega...@cse.uta.edu wrote: Dear ASF members, We would like to propose a new project to the incubator, called MRQL. Edward J. Yoon has volunteered to be the champion for this project. The proposal draft is available at: http://wiki.apache.org/incubator/MRQLProposal We are very excited about having this opportunity to work with ASF to create an incubator project. We are looking forward to your feedback and suggestions. Best regards Leonidas Fegaras = Abstract = MRQL is a query processing and optimization system for large-scale, distributed data analysis, built on top of Apache Hadoop and Hama. = Proposal = MRQL (pronounced ''miracle'') is a query processing and optimization system for large-scale, distributed data analysis. MRQL (the MapReduce Query Language) is an SQL-like query language for large-scale data analysis on a cluster of computers. The MRQL query processing system can evaluate MRQL queries in two modes: in MapReduce mode on top of Apache Hadoop or in Bulk Synchronous Parallel (BSP) mode on top of Apache Hama. The MRQL query language is powerful enough to express most common data analysis tasks over many forms of raw ''in-situ'' data, such as XML and JSON documents, binary files, and CSV documents. MRQL is more powerful than other current high-level MapReduce languages, such as Hive and PigLatin, since it can operate on more complex data and supports more powerful query constructs, thus eliminating the need for using explicit MapReduce code. With MRQL, users will be able to express complex data analysis tasks, such as PageRank, k-means clustering, matrix factorization, etc, using SQL-like queries exclusively, while the MRQL query processing system will be able to compile these queries to efficient Java code. = Background = The initial code was developed at the University of Texas of Arlington (UTA) by a research team, led by Leonidas Fegaras. The software was first released in May 2011. The original goal of this project was to build a query processing system that translates SQL-like data analysis queries to efficient workflows of MapReduce jobs. A design goal was to use HDFS as the physical storage layer, without any indexing, data partitioning, or data normalization, and to use Hadoop (without extensions) as the run-time engine. The motivation behind this work was to built a platform to test new ideas on query processing and optimization techniques applicable to the MapReduce framework. A year ago, MRQL was extended to run on Hama. The motivation for this extension was that Hadoop MapReduce jobs were required to read their input and write their output on HDFS. This simplifies reliability and fault tolerance but it imposes a high overhead to complex MapReduce workflows and graph algorithms, such as PageRank, which require repetitive jobs. In addition, Hadoop does not preserve data in memory across consecutive MapReduce jobs. This restriction requires to read data at every step, even when the data is constant. BSP, on the other hand, does not suffer from this restriction, and, under certain circumstances, allows complex repetitive algorithms to run entirely in the collective memory of a cluster. Thus, the goal was to be able to run the same MRQL queries in both modes, MapReduce and BSP, without modifying the queries: If there are enough resources available, and low latency and speed are more important than resilience, queries may run in BSP mode; otherwise, the same queries may run in MapReduce mode. BSP evaluation was found to be a good choice when fault tolerance is not critical, data (both input and intermediate) can fit in the cluster memory, and data processing requires complex/repetitive steps. The research results of this ongoing work have already been published in conferences (WebDB'11, EDBT'12, and DataCloud'12) and the authors have already received positive feedback from researchers in academia and industry who were attending these conferences. = Rationale = * MRQL will be the first general-purpose, SQL-like query language for data analysis based on BSP. Currently, many programmers prefer to code their MapReduce applications in a higher-level query language, rather than an algorithmic language. For instance, Pig is used for 60% of Yahoo MapReduce jobs, while Hive is used for 90% of Facebook MapReduce jobs. This, we believe, will also be the trend for BSP applications, because, even though, in principle, the BSP model is very simple to understand, it is hard to develop, optimize, and maintain non-trivial BSP applications coded in a general-purpose programming language. Currently, there is no widely acceptable declarative BSP query language, although there are a few special-purpose BSP systems for graph analysis, such as Google Pregel and Apache Giraph, for machine learning, such as BSML, and for scientific data analysis. * MRQL can capture many complex data analysis
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Niall, and Greg, Just to echo Greg, +1, yes would have preferred it to have happened in the existing community then. Also, agree with Greg -- exceptions can be permitted from time to time, but I don't think graduation into existing TLP should be an accepted norm. Cheers, Chris On 3/1/13 8:55 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Dave, On 2/27/13 9:44 AM, Dave Fisher dave2w...@comcast.net wrote: [..snip..] Thanks for the examples. Each case differs. I can agree that we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP, but I don't think we should exclude a future case should it be strong enough to convince the IPMC. TL;DR here -- your point above is the one that I am trying to make/echo/make strong (minus the excluding part for me which I'll get to in a sec). Point: we do not want to encourage new podlings to come in with Plan A to be graduating into an existing TLP That's my entire point, and I think Greg's +1, and Bertrand's +1, etc. Anyone can moan and groan to go even further than that. I've been around the Foundation long enough to know that may take time/effort, etc. YMMV. That said, if another future situation comes up I don't think at least in my current POV that I would be convinced that that's ever good and that's based on my experience first hand being in many situations recently that involved this (Lucene, Hadoop, Nutch, Tika, etc.) The rest of the scenarios are dealt with at a time that there is an actual concrete example by the parties involved that need to be. Until then, we are making conjecture. The outcome I'd like to see is to echo and promote what I've labeled Point: above. Seems I'm not alone. We'll see what happens and you're welcome to your opinion, as I am to mine. Cheers, Chris That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: Would you please give me a write access to http://wiki.apache.org/incubator ?
Hi there Joe, I went ahead and granted karma. Please let me know if it works. It might not since there are spaces in your wiki username, so if it doesn't work let me know. Cheers, Chris On 2/27/13 3:04 PM, H. Joe Lee hyok...@hdfgroup.org wrote: Hi, I'd like to work on an incubation proposal through wiki. Would you please give me a write access? My wiki user name is H. Joe Lee. Thanks, -- HDF: Software that Powers Science - 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: [PROPOSAL] Curator for the Apache Incubator
Hi Guys, Sorry I have to ask the question here. If the mentors consist of PMC members on ZK (at least Pat and Mahadev), what's the problem with creating a branch in ZK and just having the code be there and getting the Curator proposed committers as committers in ZK ville, and hopefully PMC members soon thereafter. I have to agree with Greg here. Seems like Incubation is something that might not be needed. If the end result of this after N months is that Curator graduates into another set of flipping bylaw updates, and more legislation that makes these people unofficial PMC members on ZK, then I'm double triple -1 with 50 piles of coal on top. Yes, I'm still remembering the HCatalog/Hive thing here - I still don't get that. Either: (a) define Curator to be its own separate project/community, with a goal of TLP; or (b) nix Incubation and just make these guys part of ZK, on a branch now. Cheers, Chris On 2/26/13 9:40 AM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 12:22 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 26, 2013 at 8:32 AM, Benson Margulies bimargul...@gmail.com wrote: If you think that the right destination for curator is as part of ZK, then it would be good to see substantive participation of the ZK PMC in the incubation. The goal should be to 'graduate' by having the curator community be granted karma at ZK and the code folded in. This would require, I think, the ZK community to supply at least one mentor, and to have a plan in advance for the eventual votes based on success in the incubator. Hi Benson. What you're suggesting matches my current thinking. The three Curator mentors are as follows: Mahadev and I (champion) are both PMC members on ZK, Enis Söztutar is active on HBase and interested in using Curator for that project (which already uses ZK heavily). OK, that's lovely. Patrick On Tue, Feb 26, 2013 at 10:53 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah no, I was not suggesting about Curator to become subproject of ZK. I just afraid that if Curator is going as incubator it will end up as sub of ZK as merging process. Like Greg has mentioned in another reply, I would prefer Curator to be merged as a higher level ZK client. Surely project like HBase and others that relying on ZK would appreciate simpler client to ZK. Thanks, Henry On Mon, Feb 25, 2013 at 11:23 PM, Patrick Hunt ph...@apache.org wrote: On Mon, Feb 25, 2013 at 11:01 PM, Henry Saputra henry.sapu...@gmail.com wrote: So isnt this similar to HCatalog which relying on Hive metadata service that ends up as sub project of Apache Hive? I was against having Curator as a sub when it came up on the original discussion thread, I still am. Patrick On Mon, Feb 25, 2013 at 7:10 PM, Greg Stein gst...@gmail.com wrote: My concern is that we're looking at two new committers, rather than a Curator community. Following normal Incubator work, Curator would build a community for itself. But then we'd have a community *distinct* from that of Zookeeper. And it really looks like this should be part of Zookeeper itself -- a more capable and easier-to-use client. So I question the incubation of this. Why do we want to build a new/separate project? Why isn't this just part of Zookeeper right from the start? I would suggest that this work is placed on a branch within Zookeeper. That Jordan and Jay become committers on that branch (not necessarily Zookeeper trunk). Over time, the branch can be folded into trunk, along with all the various tests, doc, and other artifacts that I see in the GitHub repository. And hopefully that Jordan and Jay become regular committers (and PMC members!) of the Zookeeper project itself. The current Zookeeper client can remain for backwards compat, and the Curator work can become the next-gen client. Honestly, in my opnion, incubating this project seems like it would create a distinct community, and really doesn't seem like it would serve the Zookeeper community. All that said, I am not familiar with the Zookeeper or Curator communities. But from this read, I don't think Incubation is the right approach. I would rather push for a more direct incorporation of Curator directly into Zookeeper. (use the short-form IP clearance) ... so, unless somebody can help me understand the communities and situation better, I'm -1 (binding) on this incubation. I'd rather see combined, rather than distinct, communities from the start. Thanks, -g On Mon, Feb 25, 2013 at 8:14 PM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Hello, I would like to propose that Curator to be an Apache Incubator project. The proposal can be found here: http://wiki.apache.org/incubator/CuratorProposal I have included the contents of the proposal below. Sincerely, Jordan Zimmerman === = Curator - ZooKeeper client
Re: [PROPOSAL] Curator for the Apache Incubator
Hi Jordan, On 2/26/13 11:48 AM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: My viewpoint: I can see benefit to Curator both as a TLP and as part of ZK. One of my hopes of this process is to get an idea of what the community wants. Curator has been doing well outside of Apache. But, it's become clear to me that limited devs - single company is a hinderance to wider adoption and growth of Curator. It's because of this that I thought the Incubator would be the perfect place for Curator at this point. From the FAQ: * The Incubator, among other things, is where the due-diligence of making sure the licence is correct * The Incubator is also the place where projects can familiarize themselves with how the ASF works under the guidance of Incubator PMC members Also, my reading of the Incubator docs shows that graduation does not necessarily mean TLP. I was hoping that, via Incubation, Curator's future could be explored and defined. If that means a Curator TLP, that's great. If it means something else, that's great too. Quoting Incubator docs written by one or two or a small handful of people in a committee with 100+ members: http://people.apache.org/committers-by-project.html#incubator-pmc Isn't exactly quoting scripture or anything. :) I've been on the committee for a while and at the ASF since 2005, and thus have seen things that have or haven't made their way into those docs, that I know to be true. It's really volunteer driven. Yes, I know, we'd like it to be doctrine but in an org like this it isn't. That being said, I get what you guys are trying to do and I support Incubation. I don't support Graduation-existing TLP. The Incubator is not a home for projects that end up in an existing TLP in my mind (and in several other people's that have been hanging around here for a while). So, if your goal is to eventually get into ZK, I just don't think the Incubator is the right way. It sounds like you guys are a distinct project anyways, so I would recommend going that way. My 2c. Cheers, Chris -Jordan On Feb 26, 2013, at 10:30 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Guys, Sorry I have to ask the question here. If the mentors consist of PMC members on ZK (at least Pat and Mahadev), what's the problem with creating a branch in ZK and just having the code be there and getting the Curator proposed committers as committers in ZK ville, and hopefully PMC members soon thereafter. I have to agree with Greg here. Seems like Incubation is something that might not be needed. If the end result of this after N months is that Curator graduates into another set of flipping bylaw updates, and more legislation that makes these people unofficial PMC members on ZK, then I'm double triple -1 with 50 piles of coal on top. Yes, I'm still remembering the HCatalog/Hive thing here - I still don't get that. Either: (a) define Curator to be its own separate project/community, with a goal of TLP; or (b) nix Incubation and just make these guys part of ZK, on a branch now. Cheers, Chris On 2/26/13 9:40 AM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 12:22 PM, Patrick Hunt ph...@apache.org wrote: On Tue, Feb 26, 2013 at 8:32 AM, Benson Margulies bimargul...@gmail.com wrote: If you think that the right destination for curator is as part of ZK, then it would be good to see substantive participation of the ZK PMC in the incubation. The goal should be to 'graduate' by having the curator community be granted karma at ZK and the code folded in. This would require, I think, the ZK community to supply at least one mentor, and to have a plan in advance for the eventual votes based on success in the incubator. Hi Benson. What you're suggesting matches my current thinking. The three Curator mentors are as follows: Mahadev and I (champion) are both PMC members on ZK, Enis Söztutar is active on HBase and interested in using Curator for that project (which already uses ZK heavily). OK, that's lovely. Patrick On Tue, Feb 26, 2013 at 10:53 AM, Henry Saputra henry.sapu...@gmail.com wrote: Ah no, I was not suggesting about Curator to become subproject of ZK. I just afraid that if Curator is going as incubator it will end up as sub of ZK as merging process. Like Greg has mentioned in another reply, I would prefer Curator to be merged as a higher level ZK client. Surely project like HBase and others that relying on ZK would appreciate simpler client to ZK. Thanks, Henry On Mon, Feb 25, 2013 at 11:23 PM, Patrick Hunt ph...@apache.org wrote: On Mon, Feb 25, 2013 at 11:01 PM, Henry Saputra henry.sapu...@gmail.com wrote: So isnt this similar to HCatalog which relying on Hive metadata service that ends up as sub project of Apache Hive? I was against having Curator as a sub when it came up on the original discussion thread, I still am. Patrick On Mon, Feb 25, 2013 at 7:10 PM
Re: [PROPOSAL] Curator for the Apache Incubator
Hi Luciano, On 2/26/13 12:03 PM, Luciano Resende luckbr1...@gmail.com wrote: +1, We don't need to discuss exit criteria before entering incubation. Actually we do and I can. Else I'm pretty useless on the IPMC. I just went through an experience where my objection/VOTE didn't really mean anything in a situation that I didn't think was correct (see HCatalog/Hive). I will be darned sure to discuss exit criteria now as I wish I would have paid attention and done so then, would have saved hassle all around. And if the Zookeeper PMC wants to adopt Curator as part of the Zookeeper project (see distinction from sub-project language, which is what the Board does not favor), they can work with the community and do it Define working with the community. My definition of that doesn't include entering the Incubator. My definition of that means, Pat or someone else on the ZK PMC starts getting Curator patches and/or committing them and Jordan or Jay become Committers/PMC members on ZK because of those contributions (and have their ICLAs on file, etc.) Having said that, the exit criteria should really be an option instead of being dictated. I'm questioning graduation to an existing TLP (and not as a new one) as a valid exit criteria of the Incubator. I don't think it makes sense. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Curator for the Apache Incubator
Hi Jordan, Thanks. To be clear, I'll be in support of your guys' acceptance into the Apache Incubator. I would appreciate at some level a note in your proposal regarding at least the concern by one member of the IPMC that Curator should grow into its own TLP rather than be a part of ZK should it be accepted. I'm just trying to share experience here which suggests to me you guys shouldn't try and graduate into a part of the ZK PMC if you go the Incubation route. By the #s, most projects That go through the Incubator end up as TLPs. I think it's just the way to go. Take care and good luck. Cheers, Chris On 2/26/13 1:17 PM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: Quoting Incubator docs written by one or two or a small handful of people in a committee with 100+ members: I'm new to this, so I apologize in advance for oddities in etiquette ;) So, if your goal is to eventually get into ZK, I just don't think the Incubator is the right way. It sounds like you guys are a distinct project anyways, so I would recommend going that way. I honestly don't know what the best ending spot for Curator is. I was hoping Incubator would sort that out. Of course, I want to defer to the experience of long-time Apache members, though. -Jordan - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Benson, On 2/26/13 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: On Tue, Feb 26, 2013 at 5:04 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Feb 26, 2013 at 1:52 PM, Greg Stein gst...@gmail.com wrote: ...I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns +1 to both, assuming Legal Affairs accepts 2) Guys, this was my point a few weeks ago, and the question I posed to the board. Did the board discuss it at the meeting, or is that part of the board meeting happening here? And it was my point during the whole HCatalog thing too. And Greg's when it was discussed during the board meeting. So yes, I think that's what we're discussing here. I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). 2. If an existing TLP wants to incorporate an existing non-Apache community, the incubator _might_ might serve a useful role. Or, not. I'm also perfectly happy to tell that TLP to make a branch and grant some commit access and vote status as appropriate as things proceed, which is how I'd restate your views. Right, not sure the views need restating. I think they've been stated fairly clearly so far. 3. We do have a group of people with some minimal, observed, willingness to pay some attention to IP clearance. Legal affairs, well, is more of a talking-shop. So I'd expect Sam to want some helpers before he'd accept this. How about we start letting people talk for themselves? I sense an inclination at least in this email to not do that :) Cheers, Chris -Bertrand - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Benson, On 2/26/13 2:58 PM, Benson Margulies bimargul...@gmail.com wrote: [..snip..] I think that there are several hairs worth splitting here. 1. Merging into a TLP is a possible outcome for a podling, even when the initial intention is to graduate independently. Even if we eliminate this as a starting intention, we should clarify how we expect this to happen. My prior email suggested a very low-overhead view of such events. It's my intention that that *should not be a possible outcome for a podling*. And just because we never said it explicitly (or maybe we did), that doesn't mean it was universally accepted either. You can gauge this by pure numbers of how many podlings have went this route (comparatively few). Chris, I am now confused. If a podling bogs down, and then finds that there is a congenial home for the code in an existing project, what's your desire? My suggestion that the existing project just adopt them with no formal graduation? Something else? If a podling bogs down, and then finds there is a congenial home in an existing project, I would have the following questions: To the TLP and to the Incubator community: 0. What does bogged down mean? Needs specific definition. 1. Did the podling propose to assimilate into TLP? a. If so, why did it have to bog down before getting TLP interested? b. If not, then why show up as a TLP when the podling bogged down and then assimilate? I would hope it's not for skirting IP issues, or something else like that? Also, to borrow from Sam Ruby, I prefer not to speak in hypotheticals, but to speak from actual examples, so can you point to a situation when this has happened either recently or at all? (I'll use a specific one below) To the TLP 1. Do you care about the size of the podling? If it's a fairly substantial contribution, I would wonder how the TLP could assimilate the codebase, and would worry about putting that type of burden on the PMCs. We don't ask our PMCS to take on code clearing, and IP. And to be honest, if we are asking our PMCs to do that, why do we have the meta committee of the Incubator again? To the podling 1. Why choose the TLP now? I would imagine if a podling got bogged down then the act of choosing a TLP to accept it would have been premeditated and not out of the blue. So, yes, with those questions above, I still don't think that Incubator-existing TLP is a valid exit. Let's take HCatalog as an example. I don't support that for many of the reasons previously stated. I see that not as them getting bogged down, but simply that's what they had planned from the beginning. However, what I questioned (and still question to this day) was the means of executing that plans. They didn't intersect (or union) the PMC of Hive and the PPMC of HCatalog. They induced bylaws to deal with it in Hive, and then went their separate way into Hive. Greg and the board discussed this on the last board call. I don't think that this specific example is a good one to set -- I was on the board call for the first 30 mins, but I missed this part of the discussion. So, I'm not going to speak for those on the board call RE: this subject. My personal opinion is that that specific example should *not* be allowed to happen anymore and that the Hive/HCatalog integration should also be watched to make sure those PMCs are unioned (or intersected) very soon. Let's take Curator as an example now. Put simply if the intention of Curator is to form a *new* TLP, I'm +1 on its entry into the Incubator. If there is some contingent that thinks Curator can become part of the ZK project as a product or some other form of the community, then I am -1 on Incubation for Curator. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wiki privs
I took care of granting this karma, after Gav provided it to me via an IRC chat. Cheers, Chris On 2/19/13 7:04 PM, Arun C Murthy a...@hortonworks.com wrote: Help, please? I got one of my other mentors to put up the wiki, but would be nice to get write access as well. thanks! Arun On Feb 18, 2013, at 3:05 PM, Arun C Murthy wrote: Hi Folks, Can someone pls grant me privs so that I can put up a new Incubator proposal on the wiki (http://wiki.apache.org/incubator/TezProposal) ? My wiki username is 'Arun C Murthy'. thanks, Arun - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Tez into Incubator
+1 (binding) Thanks! Cheers, Chris On 2/19/13 8:26 PM, Arun C Murthy a...@hortonworks.com wrote: Hi Folks, Thanks for participating in the discussion. I'd like to call a VOTE for acceptance of Apache Tez into the Incubator. I'll let the vote run till into this weekend (Sun 2/24 6pm PST). [ ] +1 Accept Apache Tez into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Tez into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/TezProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Here's my +1 (binding). thanks, Arun PS: From the initial discussion, the only changes are that I've added one new mentor and 2 new committers. All the new additions come from the non-major employer while we continue to strive to further diversify during the incubation. Thanks. = Tez = == Abstract == Tez is an effort to develop a generic application framework which can be used to process arbitrarily complex data-processing tasks and also a re-usable set of data-processing primitives which can be used by other projects. == Proposal == Tez is a proposal to develop a generic application which can be used to process complex data-processing task DAGs and runs natively on Apache Hadoop YARN. YARN is a generic resource-management system on which currently applications like MapReduce already exist. MapReduce is a specific, and constrained, DAG - which is not optimal for several frameworks like Apache Hive and Apache Pig. Furthermore, we propose to develop a re-usable set of libraries of data-processing primitives such as sorting, merging, data-shuffling, intermediate data management etc. which are necessary for Tez which we envision can be used directly by other projects. == Background == Apache Hadoop MapReduce has emerged as the assembly-language on which other frameworks like Apache Pig and Apache Hive have been built. However, it has been well accepted that MapReduce produces very constrained task DAGs for each job which results in Apache Pig and Apache Hive requiring multiple MapReduce jobs for several queries. By providing a more expressive DAG of tasks for a job, Tez attempts to provide significantly enhanced data-processing capabilities for projects like Apache Pig, Apache Hive, Cascading etc. == Rationale == There is an important gap that Tez fulfills in the Apache Hadoop ecosystem of allowing for more expressive task DAGs for data-processing applications such as Apache Pig, Apache Hive, Cascading etc. With emergence of Apache Hadoop YARN, there is a strong need for a common DAG application which can then be shared by Apache Pig, Apache Hive, Cascading etc. == Initial Goals == The initial goals for this project are to specify the detailed requirements and architecture, and then develop the initial implementation including the DAG ApplicationMaster to run natively inside Apache Hadoop YARN. == Current Status == Significant work has been completed to identify the initial requirements and define the overall system architecture. There is a patch available in the internal Hortonworks git repository which can act as the initial seed. === 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 generic DAG application for data processing in the open source is tremendous, so there is a potential for a very large community. We believe that Tez's extensible architecture will further encourage community participation. Also, related Apache projects (eg, Pig, Hive) have very large and active communities, and we expect that over time Tez will also attract a large community. === Core Developers === The developers on the initial committers list include people very experienced in the Apache Hadoop ecosystem: * Alan Gates gates at apache dot org * Arun C Murthy acmurthy at apache dot org * Ashutosh Chauhan hashutosh at apache dot org * Bikas Saha bikas at apache dot org * Chris Douglas cdouglas at apache dot org * Daryn Sharp daryn at apache dot org * Devaraj Das ddas at apache dot org * Gopal Vijayaraghavan gopal at hortonworks dot com * Gunther Hagleitner ghagleitner at hortonworks dot com * Hitesh Shah hitesh at apache dot org * Jason Lowe jlowe at apache dot org * Jean Xu jeanxu at facebook dot com * Jitendra Pandey jitendra at apache dot org * Julien Le Dem julien at apache dot org * Kevin Wilfong kevinwilfong at apache dot org * Mike Liddell mike dot lidell at microsoft dot com * Namit Jain namit at apache dot org * Nathan Roberts nroberts at yahoo dash inc dot com * Owen O'Malley omalley at apache dot
Re: First draft of slides for ApacheCon
Hi Benson, Looking really good! You may consider adding a flow chart/diagram showing the Incubator process but other than that, I don't have any suggestions. Wonderful! Cheers, Chris On 2/16/13 10:54 AM, Benson Margulies bimargul...@gmail.com wrote: https://docs.google.com/presentation/d/1XSqXy9rz-RDcE-P2cK7dEmyjGGHvK8--mR 4k_E-qAL4/edit?usp=sharing I've made my first pass at the slides for the talk I'm giving on the incubator in Portland. If anyone is really allergic to Google Docs, I can export it and put it somewhere otherwise accessible. - 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 Apache Knox Hadoop Gateway Project into the Incubator
+1 binding. Cheers, Chris Sent from my iPad On Feb 15, 2013, at 11:23 AM, Devaraj Das d...@hortonworks.com wrote: Hi Folks, Thanks for participating in the discussion. I'd like to call a VOTE for acceptance of Apache Knox Hadoop Gateway Project into the Incubator. The vote will close on Feb 22 at 6:00 p.m. [ ] +1 Accept Apache Knox Hadoop Gateway Project into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Knox Hadoop Gateway Project into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/knox. Only VOTEs from Incubator PMC members are binding. Here's my +1 (binding). Thanks, Devaraj. - Knox Gateway Proposal Abstract Knox Gateway is a system that provides a single point of secure access for Apache Hadoop clusters. Proposal The Knox Gateway (“Gateway” or “Knox”) is a system that provides a single point of authentication and access for Apache Hadoop services in a cluster. The goal is to simplify Hadoop security for both users (i.e. who access the cluster data and execute jobs) and operators (i.e. who control access and manage the cluster). The Gateway runs as a server (or cluster of servers) that serve one or more Hadoop clusters. Provide perimeter security to make Hadoop security setup easier Support authentication and token verification security scenarios Deliver users a single cluster end-point that aggregates capabilities for data and jobs Enable integration with enterprise and cloud identity management environments Background An Apache Hadoop cluster is presented to consumers as a loose collection of independent services. This makes it difficult for users to interact with Hadoop since each service maintains it’s own method of access and security. As well, for operators, configuration and administration of a secure Hadoop cluster is a complex and many Hadoop clusters are insecure as a result. The goal of the project is to provide coverage for all existing Hadoop ecosystem projects. In addition, the project will be extensible to allow for new and/or proprietary Hadoop components without requiring changes to the gateway source code. The gateway is expected to run in a DMZ environment where it will provide controlled access to these Hadoop services. In this way Hadoop clusters can be protected by a firewall and only limited access provided through the firewall for the gateway. The authentication components of the gateway will be modular and extensible such that it can be integrated with existing security infrastructure. Rationale Organizations that are struggling with Hadoop cluster security result in a) running Hadoop without security or b) slowing adoption of Hadoop. The Gateway aims to provide perimeter security that integrates more easily into existing organizations’ security infrastructure. Doing so will simplify security for these organizations and benefit all Hadoop stakeholders (i.e. users and operators). Additionally, making a dedicated perimeter security project part of the Apache Hadoop ecosystem will prevent fragmentation in this area and further increase the value of Hadoop as a data platform. Current Status Prototype available, developed by the list of initial committers. Meritocracy We desire to build a diverse developer community around Gateway following the Apache Way. We want to make the project open source and will encourage contributors from multiple organizations following the Apache meritocracy model. Community We hope to extend the user and developer base in the future and build a solid open source community around Gateway. Apache Hadoop has a large ecosystem of open source projects, each with a strong community of contributors. All project communities in this ecosystem have an opportunity to participate in the advancement of the Gateway project because ultimately, Gateway will enable the security capabilities of their project to be more enterprise friendly. Core Developers Gateway is currently being developed by several engineers from Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower and Sumit Mohanty. All the engineers have deep expertise in middleware, security identity systems and are quite familiar with the Hadoop ecosystem. Alignment The ASF is a natural host for Gateway given that it is already the home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data software projects. Gateway is designed to solve the security challenges familiar to the Hadoop ecosystem family of projects. Known Risks Orphaned products Reliance on Salaried Developers The core developers plan to work full time on the project. We believe that this project will be of general interest to many Hadoop users and will attract a diverse set of contributors. We intend to demonstrate this by having contributors
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Hey Alan, Great point -- thanks for highlighting the concern, and yes, Benson, I'd like the Incubator PMC to request this clarification from the board. BTW, not frustrated with you guys at all and wish you the best. Just trying to help (even if it didn't seem like it) based on my existing experience with several of Apache's largest umbrella projects :/ Cheers, Chris On 2/14/13 8:31 AM, Alan Gates ga...@hortonworks.com wrote: I'd like second and extend Benson's point about clarifying how these things should work. In addition to clarifying what it means to graduate into a subproject now that that is frowned upon, clarifying how these votes work would help. I think Chris felt that we ignored his vote and pushed ahead. From my reading of the docs it was supposed to be a majority vote and thus to view the -1s as a veto would be to improperly ignore the 5 +1s. If the rules were clear in advance for the next group that faces this situation it will help to avoid these misunderstandings and frustrations. Alan. On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: I'm not so much opinionated as confused here, perhaps because I have a very linear view of governance. I like to know how a vote fits into a governance structure or process, and I've felt for some time that this case (podling goes to existing TLP) is not well-explained by our structure. Back in the days when subprojects were normal and valid, the incubator had a role on behalf of' an existing TLP in supervising IP and community behavior. Graduation meant: OK, umbrella, we certify that these people can behave like a project and have clean IP. And, perhaps, the board actually established subprojects? It's all before my time. Now that subprojects are no longer in the picture, I don't even know why the IPMC should ever incubate a podling *if the plan, from the start, is to be part of some existing TLP.* So I have assumed that HCatalog started out with the intention to grow into an entire TLP, and came up with the Hive plan as a fallback. To try to make this long story shorter, I think that we should make a proposal to the board with a schema for handling this case that makes sense in current conditions. I'm happy for it to be your schema, which amounts, as I see it, to the board having a supervisory moment when this happens, with an IPMC vote providing the same sort of strong recommendation one way or the other that it does for establishing a TLP. On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, I saw your later email(s) and Incubator board report. It's fine and I think the message of my objection comes across. So thanks for that. One thing I wanted to comment on: On 2/13/13 4:10 AM, Benson Margulies bimargul...@gmail.com wrote: Chris, The obvious compromise is to ask them to report the vote result as it happened, it seems to me, -1's and all. But where do you think that they are reporting anything? There's nothing happening here at the board level. There's no board resolution needed for a Hive committer to type 'svn cp' on the hcatalog tree, Not by my counts. There's a *community* resolution and a recommendation to be made by the IPMC, nonetheless. Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the Incubator. Why bother even incubating HCatalog? Hive could have simply svn cp'ed whatever code came in, or whatever code the podling arrived at, and Incubation would have stopped then. But we both know that's not the way it works. Even if a podling graduates to an existing TLP, go check out the past resolutions. You'll note there's a section in there that discharges the responsibility of the IPMC for the podling. So, yes, the IPMC *is* involved. And yes, the IPMC vote matters. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator
s/Apache Open Climate Workbench/Apache Knox Hadoop Gateway/ :) May want to resend the [VOTE] thread. On 2/14/13 5:26 PM, Devaraj Das d...@hortonworks.com wrote: Hi Folks, Thanks for participating in the discussion. I'd like to call a VOTE for acceptance of Apache Knox Hadoop Gateway Project into the Incubator. The vote will close on Feb 21 at 6:00 p.m. [ ] +1 Accept Apache Open Climate Workbench into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Open Climate Workbench into the Incubator because... Full proposal is pasted at the bottom of this email, and the corresponding wiki is http://wiki.apache.org/incubator/knox. Only VOTEs from Incubator PMC members are binding. Here's my +1 (binding). Thanks, Devaraj. p.s. In the last day, Tom White has been added as a mentor, and Venkatesh Seetharam has been added in the list of initial committers. Knox Gateway Proposal Abstract Knox Gateway is a system that provides a single point of secure access for Apache Hadoop clusters. Proposal The Knox Gateway (³Gateway² or ³Knox²) is a system that provides a single point of authentication and access for Apache Hadoop services in a cluster. The goal is to simplify Hadoop security for both users (i.e. who access the cluster data and execute jobs) and operators (i.e. who control access and manage the cluster). The Gateway runs as a server (or cluster of servers) that serve one or more Hadoop clusters. Provide perimeter security to make Hadoop security setup easier Support authentication and token verification security scenarios Deliver users a single cluster end-point that aggregates capabilities for data and jobs Enable integration with enterprise and cloud identity management environments Background An Apache Hadoop cluster is presented to consumers as a loose collection of independent services. This makes it difficult for users to interact with Hadoop since each service maintains it¹s own method of access and security. As well, for operators, configuration and administration of a secure Hadoop cluster is a complex and many Hadoop clusters are insecure as a result. The goal of the project is to provide coverage for all existing Hadoop ecosystem projects. In addition, the project will be extensible to allow for new and/or proprietary Hadoop components without requiring changes to the gateway source code. The gateway is expected to run in a DMZ environment where it will provide controlled access to these Hadoop services. In this way Hadoop clusters can be protected by a firewall and only limited access provided through the firewall for the gateway. The authentication components of the gateway will be modular and extensible such that it can be integrated with existing security infrastructure. Rationale Organizations that are struggling with Hadoop cluster security result in a) running Hadoop without security or b) slowing adoption of Hadoop. The Gateway aims to provide perimeter security that integrates more easily into existing organizations¹ security infrastructure. Doing so will simplify security for these organizations and benefit all Hadoop stakeholders (i.e. users and operators). Additionally, making a dedicated perimeter security project part of the Apache Hadoop ecosystem will prevent fragmentation in this area and further increase the value of Hadoop as a data platform. Current Status Prototype available, developed by the list of initial committers. Meritocracy We desire to build a diverse developer community around Gateway following the Apache Way. We want to make the project open source and will encourage contributors from multiple organizations following the Apache meritocracy model. Community We hope to extend the user and developer base in the future and build a solid open source community around Gateway. Apache Hadoop has a large ecosystem of open source projects, each with a strong community of contributors. All project communities in this ecosystem have an opportunity to participate in the advancement of the Gateway project because ultimately, Gateway will enable the security capabilities of their project to be more enterprise friendly. Core Developers Gateway is currently being developed by several engineers from Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower and Sumit Mohanty. All the engineers have deep expertise in middleware, security identity systems and are quite familiar with the Hadoop ecosystem. Alignment The ASF is a natural host for Gateway given that it is already the home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data software projects. Gateway is designed to solve the security challenges familiar to the Hadoop ecosystem family of projects. Known Risks Orphaned products Reliance on Salaried Developers The core developers plan to work full time on the project. We believe that this project will be of general interest to many Hadoop users and will attract a diverse set of contributors. We intend to
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC7 release
Hi Guys, +1 from me. SIGS pass: [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% $HOME/bin/verify_gpg_sigs Verifying Signature for file apache-ctakes-3.0.0-incubating-src.tar.gz.asc gpg: Signature made Wed Feb 6 14:06:28 2013 PST using RSA key ID D218BB0A gpg: Good signature from Pei Chen (CODE SIGNING KEY2) chen...@apache.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FECC 654C 4AC3 5DEC 0027 2792 F97C 492F D218 BB0A [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% CHECKSUMS pass: [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% verify_md5_checksums md5sum: stat '*.bz2': No such file or directory md5sum: stat '*.zip': No such file or directory apache-ctakes-3.0.0-incubating-src.tar.gz: OK [chipotle:~/tmp/apache-ctakes-3.0.0-incubating-rc7] mattmann% Cheers, Chris On 2/11/13 9:03 AM, Chen, Pei pei.c...@childrens.harvard.edu wrote: Hi, This is a call for a vote on releasing the following candidate as Apache cTAKES 3.0.0-incubating. This will be our first release. Thanks for all of your comments from the previous candidate. Based on the feedback and discussions, we removed the binary models from the source and binary distributions in this release candidate. The vote for this RC on ctakes-dev@ is not concluded yet but earlier ones were and this is nearly simultaneous: http://mail-archives.apache.org/mod_mbox/incubator-ctakes-dev/201302.mbox/ browser For more detailed information on the changes/release notes, please visit: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313621; version=12322969 The release was made using the cTAKES release process documented here: http://incubator.apache.org/ctakes/ctakes-release-guide.html The candidate is available at: http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach e-ctakes-3.0.0-incubating-src.tar.gz /.zip The binary is: http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach e-ctakes-3.0.0-incubating-bin.tar.gz /.zip The tag to be voted on: http://svn.apache.org/repos/asf/incubator/ctakes/tags/ctakes-3.0.0-incubat ing-rc7/ The MD5 checksum of the tarball can be found at: http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach e-ctakes-3.0.0-incubating-bin.tar.gz.md5 /.zip.md5 The signature of the tarball can be found at: http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc7/target/apach e-ctakes-3.0.0-incubating-bin.tar.gz.asc /.zip.asc Apache cTAKES' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/ctakes/tags/ctakes-3.0.0-incubat ing-rc7/KEYS Please vote on releasing these packages as Apache cTAKES 3.0.0-incubating. The vote is open for at least the next 72 hours. Only votes from Incubator PMC are binding, but folks are welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. [ ] +1 Release the packages as Apache cTAKES 3.0.0-incubating [ ] -1 Do not release the packages because... Thanks! Pei P.S. Here is my +1. - 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
[RESULT] [VOTE] Accept Apache Open Climate Workbench into the Incubator
Hi Everyone, This VOTE has passed with the following tallies: +1 Chris Mattmann* Andrew Hart* Daniel Gruno Paul Ramirez* Gary Martin Ross Gardler* Ted Dunning* Alexei Fedotov Dave Fisher* Suresh Marru* Tommaso Teofili* Andrea Pescetti Chris Douglas* Emmanuel Lécharny* Tsengdar Lee * - indicates IPMC I'll get started creating the infrastructure tickets, and thanks to everyone for VOTE'ing! Cheers, Chris On 2/5/13 8:18 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Folks, OK, now that discussion has settled down, I'd like to call a VOTE for acceptance of Apache Open Climate Workbench into the Incubator. I'll leave the VOTE open the rest of the week and close it out next Monday, February 11th early am PT. [ ] +1 Accept Apache Open Climate Workbench into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Open Climate Workbench into the Incubator because... Full proposal is pasted at the bottom of this email. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thank you! Cheers, Chris P.S. Here's my +1 (binding) - = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing data grid. The regridded data spatially is then temporally regridded using techniques including seasonal cycle compositing (e.g., all summer months, all Januaries, etc.), or by daily, monthly, etc. The uniform model output and remote sensing data are then analyzed using pluggable metrics, e.g., Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), Bias, and other (possibly user-defined) techniques, computing an analyzed comparison or evaluation. This evaluation is then visualized by plugging in to the NCAR NCL library for producing static plots (histograms, time series, etc.) We also have performed a great deal of work in packaging RCMES to make the system easy to deploy. We have working Virtual Machines (VMWare VMX and Virtual Box OVA compatible formats) and we also have an installer built on Python Buildout (http://buildout.org/) called Easy RCMET for dynamically constructing the RCMET toolkit. RCMES is currently supporting a number of recognized climate projects of (inter-)national significance. In particular, RCMES is supporting the [[http://www.globalchange.gov/what-we-do/assessment|U.S. National Climate Assessment (NCA) activities]] on behalf of NASA's contribution to the NCA; is working with the [[http://www.narccap.ucar.edu/|North American Regional Climate Change Assessment Program (NARCCAP)]]; and is also working with the International [[http://wcrp-cordex.ipsl.jussieu.fr/|Coordinated Regional Downscaling Experiment (CORDEX)]]. === Proposal === We propose to transition the RCMES software community, which includes developers of the RCMET and RCMED software, along with users of RCMES in the CORDEX project across a variety of academic institutions, scientists
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Thanks for the clarification, Roy. Cheers, Chris P.S. Almost want them to change to lazy consensus, bc you laying smack down is full of win. On 2/14/13 11:38 AM, Roy T. Fielding field...@gbiv.com wrote: It is a majority decision. In theory, the PMC could decide to create special bylaws that would change that to a lazy consensus decision, but then I would have to lay the smack down about why it is that the US government sucks because supermajorities are designed to deny proper governance. In the absence of specific rules (like our lazy consensus rule on code change voting), you can assume that lazy majority decisions are the way that decisions are made at Apache (like releases). Roy On Feb 14, 2013, at 9:58 AM, Mattmann, Chris A (388J) wrote: Hey Alan, Great point -- thanks for highlighting the concern, and yes, Benson, I'd like the Incubator PMC to request this clarification from the board. BTW, not frustrated with you guys at all and wish you the best. Just trying to help (even if it didn't seem like it) based on my existing experience with several of Apache's largest umbrella projects :/ Cheers, Chris On 2/14/13 8:31 AM, Alan Gates ga...@hortonworks.com wrote: I'd like second and extend Benson's point about clarifying how these things should work. In addition to clarifying what it means to graduate into a subproject now that that is frowned upon, clarifying how these votes work would help. I think Chris felt that we ignored his vote and pushed ahead. From my reading of the docs it was supposed to be a majority vote and thus to view the -1s as a veto would be to improperly ignore the 5 +1s. If the rules were clear in advance for the next group that faces this situation it will help to avoid these misunderstandings and frustrations. Alan. On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: I'm not so much opinionated as confused here, perhaps because I have a very linear view of governance. I like to know how a vote fits into a governance structure or process, and I've felt for some time that this case (podling goes to existing TLP) is not well-explained by our structure. Back in the days when subprojects were normal and valid, the incubator had a role on behalf of' an existing TLP in supervising IP and community behavior. Graduation meant: OK, umbrella, we certify that these people can behave like a project and have clean IP. And, perhaps, the board actually established subprojects? It's all before my time. Now that subprojects are no longer in the picture, I don't even know why the IPMC should ever incubate a podling *if the plan, from the start, is to be part of some existing TLP.* So I have assumed that HCatalog started out with the intention to grow into an entire TLP, and came up with the Hive plan as a fallback. To try to make this long story shorter, I think that we should make a proposal to the board with a schema for handling this case that makes sense in current conditions. I'm happy for it to be your schema, which amounts, as I see it, to the board having a supervisory moment when this happens, with an IPMC vote providing the same sort of strong recommendation one way or the other that it does for establishing a TLP. On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, I saw your later email(s) and Incubator board report. It's fine and I think the message of my objection comes across. So thanks for that. One thing I wanted to comment on: On 2/13/13 4:10 AM, Benson Margulies bimargul...@gmail.com wrote: Chris, The obvious compromise is to ask them to report the vote result as it happened, it seems to me, -1's and all. But where do you think that they are reporting anything? There's nothing happening here at the board level. There's no board resolution needed for a Hive committer to type 'svn cp' on the hcatalog tree, Not by my counts. There's a *community* resolution and a recommendation to be made by the IPMC, nonetheless. Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the Incubator. Why bother even incubating HCatalog? Hive could have simply svn cp'ed whatever code came in, or whatever code the podling arrived at, and Incubation would have stopped then. But we both know that's not the way it works. Even if a podling graduates to an existing TLP, go check out the past resolutions. You'll note there's a section in there that discharges the responsibility of the IPMC for the podling. So, yes, the IPMC *is* involved. And yes, the IPMC vote matters. Cheers, Chris - 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
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Hi Benson, I saw your later email(s) and Incubator board report. It's fine and I think the message of my objection comes across. So thanks for that. One thing I wanted to comment on: On 2/13/13 4:10 AM, Benson Margulies bimargul...@gmail.com wrote: Chris, The obvious compromise is to ask them to report the vote result as it happened, it seems to me, -1's and all. But where do you think that they are reporting anything? There's nothing happening here at the board level. There's no board resolution needed for a Hive committer to type 'svn cp' on the hcatalog tree, Not by my counts. There's a *community* resolution and a recommendation to be made by the IPMC, nonetheless. Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the Incubator. Why bother even incubating HCatalog? Hive could have simply svn cp'ed whatever code came in, or whatever code the podling arrived at, and Incubation would have stopped then. But we both know that's not the way it works. Even if a podling graduates to an existing TLP, go check out the past resolutions. You'll note there's a section in there that discharges the responsibility of the IPMC for the podling. So, yes, the IPMC *is* involved. And yes, the IPMC vote matters. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Classifying this as a procedural vote gives the easy out of majority rule. It is the IPMC's recommendation to the board that the board then evaluates to become a TLP or not. Based on Benson's later email he is shucking all of that to the board. Benson, I would hope you consider -1s to be VETO in this case, or at the very least, noting that in your report should you still bull ahead and recommend it. BTW for everyone's benefit, go look up the # of times that people -1 graduations. It's VERY rare, so I hope this an indication that there is something seriously up here. I have nothing against Hive or HCatalog -- I simply am trying to intimate this will be trouble down the road. In the end, yes, it's the board, but it's on the recommendation of the IPMC. It would be pretty lame if the IPMC made the recommendation to create HCatalog as a part of Hive per the requested method and they didn't mention the 2 objections (mine which I strongly consider a VETO) and Chris D.'s -0. Chris On 2/12/13 5:14 PM, Alan Gates ga...@hortonworks.com wrote: So I'm not clear what the next step is here. The 72 hours have passed, we have 5 +1 votes, 2 -1 votes, and a -0. Based on this page http://www.apache.org/foundation/voting.html this appears to be a procedural vote so it just requires a majority. Are we done or is it traditional to allow more time for the vote when the issue is contentious? Alan. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Hi Alan,
On 2/11/13 10:20 AM, Alan Gates ga...@hortonworks.com wrote:
On Feb 8, 2013, at 9:03 PM, Mattmann, Chris A (388J) wrote:
Hi Alan,
Thanks for the pointer.
I'm -1 on this graduation for the following reasons:
1. It looks eerily similar to the creation of umbrella projects. I would
expect the ASF board to not be happy with the graduation of a podling as
effectively a sub project of an established TLP, with the sub project
status maintained through a rather lengthy set of bylaws that after
trying
to read through for about 5 mins I decided to stop. TL;DR
Our goal is not to repeat the umbrella project situation that happened
with Hadoop. The goal is to give the Hive community time to get to know
the HCatalog committers and time for the HCatalog community to learn
about Hive beyond the metadata portions they have been working with.
IMO, the above statement conflicts with the below statement:
{quote}
Because we believe it makes sense, from both a community and code
perspective, that these projects are together. HCatalog opens up Hive's
metadata for use by other tools on Hadoop and for external systems. It
doesn't make sense to any of us that this is separated from Hive with a
different PMC, different release cycle, etc.
{quote}
If it makes sense from a community and code perspective to bring the
projects together, there shouldn't be a need for time from the Hive
community to get to know HCatalog (or vice versa). Either they know the
code and/or are willing to take on its stewardship (which kind of
necessitates knowing the code), or they don't.
To avoid the umbrella project status the by laws specifically prohibit
creating new committers with access only to HCatalog. Also, it has been
agreed that each HCatalog committer will be provided with a mentor from
the Hive community to help him/her learn the rest of Hive, with the goal
of becoming a committer on Hive within six months. The submodule state
is transitionary, not an end point.
Why introduce a transitionary state then? If in 6 months Hive and HCatalog
are ready to merge, you can just as easily create a board resolution to
merge the 2 projects at the time, the Incubator - TLP and TLP status is
not an end state.
However, I'm against setting a precedent for umbrella project creation,
which I believe this to be.
2. If the two communities can't be merged by simply merging the PPMC
into
the PMC, then why not simply graduate HCatalog as its own TLP?
Because we believe it makes sense, from both a community and code
perspective, that these projects are together. HCatalog opens up Hive's
metadata for use by other tools on Hadoop and for external systems. It
doesn't make sense to any of us that this is separated from Hive with a
different PMC, different release cycle, etc.
It's been separated while in Incubation, so nothing is changing if it
becomes a TLP, it's business as usual. And if in 6 months, the Hive PMC is
ready to accept the HCatalog PMC (and vice versa), then deal with it then
as 2 TLPs becoming 1 TLP.
But I'm not going to VOTE positively for a graduation that requires bylaws
to draw these artificial lines which already exist at the ASF and have
been around for quite a while longer than any of us have at the
Foundation.
Chris
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: January Report - missing mentor signings
Hi Jakob, No worries and appreciate it. Cheers, Chris On 2/11/13 11:25 AM, Jakob Homan jgho...@gmail.com wrote: Sorry I've not yet been as active in my recent mentorship as I needed to be. It's likely that I'll have more time shortly. -Jakob On Thu, Feb 7, 2013 at 8:13 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Guys, I think this may be pretty clear guidance that Mesos needs some mentorship help. I'm happy to help here, and I believe Suresh Marru also offered. I'm going to go ahead and subscribe to the mesos email lists and see what I can do. Cheers, Chris On 2/6/13 9:17 AM, Christian Grobmeier grobme...@gmail.com wrote: Hi all, looking at this report: http://wiki.apache.org/incubator/January2013 a lot of podlings do not have all mentors signed their report. In the case of Mesos the report looks good, but there is only one Mentor listed and he did not sign it. As I understood it the rule should be every mentor should sign the report. With that he shows he is still there. What do we do with now? I think it would be nice to ask the Mentors who did not sign if they are still available and were just short of time or if they have gone. Maybe this file can be parsed, if the template creation script would output the apache id together with the mentors name or so. Cheers Christian -- 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: Administrative access to Mesos builds on Apache Jenkins
Hi Vinod, [changing this to mesos-dev@ since there is nothing private about this request] Per: http://wiki.apache.org/general/Jenkins?action=showredirect=Hudson#How_do_I _get_an_account You need someone to run: modify_appgroups.pl hudson-jobadmin --add=Apache username with PMC chair karma. I have that karma and have run it for you. Let me know if that fixes it. Cheers, Chris On 2/6/13 2:38 PM, Vinod Kone vinodk...@gmail.com wrote: Hi, I'm a new committer to the Apache Mesos project. I was wondering what is the process to get admin access to our project's builds(1https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Set -JAVA_HOME/ ,2https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disab le-Java-Disable-Python-Disable-Webui/ ,3https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set-J AVA_HOME/) on Apache Jenkins server. NOTE: I already have login access (username: vinodkone) to Jenkins, but cannot see the configure link for our projects. Thanks, Vinod - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Administrative access to Mesos builds on Apache Jenkins
[Changing to mesos-dev@ since nothing private about this thread, and since public discussion is encouraged at Apache (and a good metric).] Hi Vinod, The folks to ask here would ASF infra, and the best bet would be to file an issue here: http://issues.apache.org/jira/browse/INFRA Requesting a Review Board account. Question: why would you ever need to mark someone else's Review Board as submitted? We operate here at Apache as individuals so not sure I get this. Cheers, Chris On 2/8/13 3:09 PM, Vinod Kone vi...@twitter.com wrote: Just realized I need the same type of access for Apache Reviewboard too, so that I can mark other people's reviews as submitted. Thanks, Vinod @vinodkone On Wed, Feb 6, 2013 at 2:38 PM, Vinod Kone vinodk...@gmail.com wrote: Hi, I'm a new committer to the Apache Mesos project. I was wondering what is the process to get admin access to our project's builds(1https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-In-Src-Se t-JAVA_HOME/ ,2https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Disa ble-Java-Disable-Python-Disable-Webui/ ,3https://builds.apache.org/job/Mesos-Trunk-Ubuntu-Build-Out-Of-Src-Set- JAVA_HOME/) on Apache Jenkins server. NOTE: I already have login access (username: vinodkone) to Jenkins, but cannot see the configure link for our projects. Thanks, Vinod - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Mesos 0.10.0-incubating (RC4)
[CC to mesos-dev@incubator] Hi Ben, +1 (binding) from me: SIGS check out: [chipotle:~/tmp/apache-mesos-0.10.0-incubating] mattmann% $HOME/bin/verify_gpg_sigs Verifying Signature for file mesos-0.10.0-incubating.tar.gz.asc gpg: Signature made Thu Feb 7 22:22:30 2013 PST using RSA key ID F6FB762C gpg: Good signature from Benjamin Hindman b...@apache.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 4BF2 061E 7300 3185 CA06 E30F F99D 6AD0 F6FB 762C [chipotle:~/tmp/apache-mesos-0.10.0-incubating] mattmann% CHECKSUMS check out (please consider including a sha1 checksum too in addition to the MD5 -- not a requirement or blocker just a preference): Primary key fingerprint: 4BF2 061E 7300 3185 CA06 E30F F99D 6AD0 F6FB 762C [chipotle:~/tmp/apache-mesos-0.10.0-incubating] mattmann% $HOME/bin/verify_md5_checksums md5sum: stat '*.bz2': No such file or directory md5sum: stat '*.zip': No such file or directory mesos-0.10.0-incubating.tar.gz: OK [chipotle:~/tmp/apache-mesos-0.10.0-incubating] mattmann% I went ahead and tried to build it and started with ./configure on my Mac OS X 10.6.8: checking whether or not we can build with JNI... cc1plus: warnings being treated as errors conftest.cpp: In function 'int main(int, char**)': conftest.cpp:7: warning: 'JNI_CreateJavaVM' is deprecated (declared at /usr/local/jdk/include/jni.h:1937) conftest.cpp:7: warning: 'JNI_CreateJavaVM' is deprecated (declared at /usr/local/jdk/include/jni.h:1937) cc1plus: warnings being treated as errors conftest.cpp: In function 'int main(int, char**)': conftest.cpp:7: warning: 'JNI_CreateJavaVM' is deprecated (declared at /System/Library/Frameworks/JavaVM.framework/Headers/jni.h:1937) conftest.cpp:7: warning: 'JNI_CreateJavaVM' is deprecated (declared at /System/Library/Frameworks/JavaVM.framework/Headers/jni.h:1937) configure: error: failed to build with JNI [chipotle:~/tmp/apache-mesos-0.10.0-incubating/mesos-0.10.0] mattmann% Running ./configure --disable-java got me past the config step, and then I ran make: writing build/bdist.macosx-10.6-universal/egg/EGG-INFO/native_libs.txt zip_safe flag not set; analyzing archive contents... creating dist creating 'dist/mesos-0.10.0-py2.6-macosx-10.6-universal.egg' and adding 'build/bdist.macosx-10.6-universal/egg' to it removing 'build/bdist.macosx-10.6-universal/egg' (and everything under it) Making all in ec2 make[1]: Nothing to be done for `all'. Making all in hadoop make[1]: Nothing to be done for `all'. [chipotle:~/tmp/apache-mesos-0.10.0-incubating/mesos-0.10.0] mattmann% Worked great! Tried running make test but got: [chipotle:~/tmp/apache-mesos-0.10.0-incubating/mesos-0.10.0] mattmann% make test make: *** No rule to make target `test'. Stop. [chipotle:~/tmp/apache-mesos-0.10.0-incubating/mesos-0.10.0] mattmann% But that's fine since everything else looks great. Awesome! Cheers, Chris On 2/7/13 10:32 PM, Benjamin Hindman b...@berkeley.edu wrote: Please vote on releasing the following candidate as Apache Mesos (incubating) version 0.10.0. This will be the second incubator release for Mesos in Apache. -- --- Changes since last release candidate: * Updated configure.ac to work better on OS X 10.8. * Added missing license (the only blocker on the previous candidate). -- --- The candidate for Mesos 0.10.0-incubating release is available at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz The tag to be voted on: https://svn.apache.org/repos/asf/incubator/mesos/tags/release-0.10.0-incub ating-RC4 The MD5 checksum of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz.md5 The signature of the tarball can be found at: http://people.apache.org/~benh/mesos-0.10.0-incubating-RC4/mesos-0.10.0-in cubating.tar.gz.asc Mesos' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/mesos/dist/KEYS Please vote on releasing this package as Apache Mesos 0.10.0-incubating! The vote is open until Monday, February 11th at 5:00 pm (PST) and passes if a majority of at least 3 +1 IPMC votes are cast. [ ] +1 Release this package as Apache Mesos 0.10.0-incubating [ ] -1 Do not release this package because ... To learn more about Apache Mesos, please see http://www.mesosproject.org. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Dear Alan, Just a quick question: does this mean that the Hive PMC += (Apache HCatalog Incubating PPMC)? Thanks. Cheers, Chris On 2/8/13 11:38 AM, Alan Gates ga...@hortonworks.com wrote: Apache HCatalog entered incubation in March of 2011. In the process it has added five new committers and two new PPMC members and made 3 successful releases. The Hive PMC has voted to accept HCatalog as a part of Hive. The vote thread for this is at http://mail-archives.apache.org/mod_mbox/hive-dev/201301.mbox/%3cCACf6Rrzk tBYD0suZxn3Pfv8XkR=vgwszrzyb_2qvesuj2vh...@mail.gmail.com%3e The HCatalog PPMC has voted to accept this invitation. The vote thread for that is at: http://mail-archives.apache.org/mod_mbox/incubator-hcatalog-dev/201302.mbo x/%3cd6cc6c77-9e4f-48f6-b49f-a7e378889...@hortonworks.com%3e additional votes for this can be found at: http://mail-archives.apache.org/mod_mbox/incubator-general/201302.mbox/%3c 3f7d9868-7d0d-4c08-831a-ff4735394...@hortonworks.com%3e and http://mail-archives.apache.org/mod_mbox/hive-dev/201302.mbox/%3c3F7D9868- 7d0d-4c08-831a-ff4735394...@hortonworks.com%3e (these are threads I forwarded to dev@hive and general@incubator as an FYI but people got confused and voted on the wrong thread). We have already received +1s from the following IPMC members on the previous threads: Arun Murthy Owen O'Malley Alex Karasulu Jakob Homan Alan Gates Please cast your vote. The vote will remain open until 12 PST Feb 11. Alan. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
Hi Alan, Thanks for the pointer. I'm -1 on this graduation for the following reasons: 1. It looks eerily similar to the creation of umbrella projects. I would expect the ASF board to not be happy with the graduation of a podling as effectively a sub project of an established TLP, with the sub project status maintained through a rather lengthy set of bylaws that after trying to read through for about 5 mins I decided to stop. TL;DR 2. If the two communities can't be merged by simply merging the PPMC into the PMC, then why not simply graduate HCatalog as its own TLP? 3. I get a little nervous every time I see bylaws used to draw artificial lines and to create new roles that don't exist at Apache. sub module committer? How is this comparable across projects? It's not really. Projects don't have to be strictly comparable, but realize that you report to the Board with common criteria, and so thus at some level projects are comparable. I'd like to understand the answers to my above questions and I'd urge other PMC members to take a look at this. It seems to be a recipe for later issues, based on past experience with Hadoop, Lucene, and other umbrellas that were dismantled. Chris On 2/8/13 4:33 PM, Alan Gates ga...@hortonworks.com wrote: No. See the thread of the Hive vote at http://mail-archives.apache.org/mod_mbox/hive-dev/201301.mbox/%3cCACf6Rrzk tBYD0suZxn3Pfv8XkR=vgwszrzyb_2qvesuj2vh...@mail.gmail.com%3e for a discussion of how the teams will be merged. Alan. On Feb 8, 2013, at 3:58 PM, Mattmann, Chris A (388J) wrote: Dear Alan, Just a quick question: does this mean that the Hive PMC += (Apache HCatalog Incubating PPMC)? Thanks. Cheers, Chris On 2/8/13 11:38 AM, Alan Gates ga...@hortonworks.com wrote: Apache HCatalog entered incubation in March of 2011. In the process it has added five new committers and two new PPMC members and made 3 successful releases. The Hive PMC has voted to accept HCatalog as a part of Hive. The vote thread for this is at http://mail-archives.apache.org/mod_mbox/hive-dev/201301.mbox/%3cCACf6Rr zk tBYD0suZxn3Pfv8XkR=vgwszrzyb_2qvesuj2vh...@mail.gmail.com%3e The HCatalog PPMC has voted to accept this invitation. The vote thread for that is at: http://mail-archives.apache.org/mod_mbox/incubator-hcatalog-dev/201302.m bo x/%3cd6cc6c77-9e4f-48f6-b49f-a7e378889...@hortonworks.com%3e additional votes for this can be found at: http://mail-archives.apache.org/mod_mbox/incubator-general/201302.mbox/% 3c 3f7d9868-7d0d-4c08-831a-ff4735394...@hortonworks.com%3e and http://mail-archives.apache.org/mod_mbox/hive-dev/201302.mbox/%3c3F7D986 8- 7d0d-4c08-831a-ff4735394...@hortonworks.com%3e (these are threads I forwarded to dev@hive and general@incubator as an FYI but people got confused and voted on the wrong thread). We have already received +1s from the following IPMC members on the previous threads: Arun Murthy Owen O'Malley Alex Karasulu Jakob Homan Alan Gates Please cast your vote. The vote will remain open until 12 PST Feb 11. Alan. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: January Report - missing mentor signings
Hi Guys, I think this may be pretty clear guidance that Mesos needs some mentorship help. I'm happy to help here, and I believe Suresh Marru also offered. I'm going to go ahead and subscribe to the mesos email lists and see what I can do. Cheers, Chris On 2/6/13 9:17 AM, Christian Grobmeier grobme...@gmail.com wrote: Hi all, looking at this report: http://wiki.apache.org/incubator/January2013 a lot of podlings do not have all mentors signed their report. In the case of Mesos the report looks good, but there is only one Mentor listed and he did not sign it. As I understood it the rule should be every mentor should sign the report. With that he shows he is still there. What do we do with now? I think it would be nice to ask the Mentors who did not sign if they are still available and were just short of time or if they have gone. Maybe this file can be parsed, if the template creation script would output the apache id together with the mentors name or so. Cheers Christian -- 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
[VOTE] Accept Apache Open Climate Workbench into the Incubator
Hi Folks, OK, now that discussion has settled down, I'd like to call a VOTE for acceptance of Apache Open Climate Workbench into the Incubator. I'll leave the VOTE open the rest of the week and close it out next Monday, February 11th early am PT. [ ] +1 Accept Apache Open Climate Workbench into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Apache Open Climate Workbench into the Incubator because... Full proposal is pasted at the bottom of this email. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thank you! Cheers, Chris P.S. Here's my +1 (binding) - = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing data grid. The regridded data spatially is then temporally regridded using techniques including seasonal cycle compositing (e.g., all summer months, all Januaries, etc.), or by daily, monthly, etc. The uniform model output and remote sensing data are then analyzed using pluggable metrics, e.g., Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), Bias, and other (possibly user-defined) techniques, computing an analyzed comparison or evaluation. This evaluation is then visualized by plugging in to the NCAR NCL library for producing static plots (histograms, time series, etc.) We also have performed a great deal of work in packaging RCMES to make the system easy to deploy. We have working Virtual Machines (VMWare VMX and Virtual Box OVA compatible formats) and we also have an installer built on Python Buildout (http://buildout.org/) called Easy RCMET for dynamically constructing the RCMET toolkit. RCMES is currently supporting a number of recognized climate projects of (inter-)national significance. In particular, RCMES is supporting the [[http://www.globalchange.gov/what-we-do/assessment|U.S. National Climate Assessment (NCA) activities]] on behalf of NASA's contribution to the NCA; is working with the [[http://www.narccap.ucar.edu/|North American Regional Climate Change Assessment Program (NARCCAP)]]; and is also working with the International [[http://wcrp-cordex.ipsl.jussieu.fr/|Coordinated Regional Downscaling Experiment (CORDEX)]]. === Proposal === We propose to transition the RCMES software community, which includes developers of the RCMET and RCMED software, along with users of RCMES in the CORDEX project across a variety of academic institutions, scientists helping to improve the RCMES metrics, and visualizations, and regridding algorithms, packagers making RCMES easier to install, and scientists helping to lead some of these international projects that are already using RCMES. We have been working on the RCMES project since 2009 funded initially by the American Recovery and Reinvestment Act (ARRA) project out at NASA, and then branching out into other sources of support and sustainability (NASA; NSF, etc. -- see the
Re: [VOTE] Graduate Apache Crunch Podling from the Incubator
+1 good luck guys. (binding) Cheers, Chris On 2/4/13 11:41 AM, Josh Wills jwi...@apache.org wrote: This is a call to graduate the Apache Crunch podling from Apache Incubator. Apache Crunch entered the Incubator in May of 2012. We have made significant progress with the project since moving over to Apache. We have ten committers listed on our status page at [1] including three accepted after the podling was formed, and we have verified that Apache Crunch is a suitable name. [2] We completed two releases (Apache Crunch 0.3.0-incubating and Apache Crunch 0.4.0-incubating) and are currently preparing for a third. The community of Apache Crunch is active, healthy, and growing and has demonstrated the ability to self-govern using accepted Apache practices. The Apache Crunch community voted overwhelmingly to graduate [3], collecting three binding votes from our mentors and IPMC members Arun Murthy, Tom White, and Patrick Hunt. You can view the discussion at [4] and [5]. Our charter is below and on our wiki. [6] Please cast your votes: [ ] +1 Graduate Apache Crunch from Apache Incubator [ ] +0 Indifferent to graduation status of Apache Crunch [ ] -1 Reject graduation of Apache Crunch from Apache Incubator because... We'll run the vote for at least 72 hours (closing at the earliest at 8PM GMT on February 7th.) [1] http://incubator.apache.org/projects/crunch.html [2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-18 [3] http://markmail.org/message/7mplf2wyzqhs2gts [4] http://markmail.org/message/3zu5wszwpaqegxic [5] http://markmail.org/message/wbz43fpnta7r2w4e [6] https://cwiki.apache.org/confluence/display/CRUNCH/Graduation+Resolution X. Establish the Apache Crunch 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, for distribution at no charge to the public, related to the development of Java libraries for writing, testing, and running MapReduce pipelines. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Crunch Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Crunch Project be and hereby is responsible for the creation and maintenance of software related to development of Java libraries for writing, testing, and running MapReduce pipelines; and be it further RESOLVED, that the office of Vice President, Apache Crunch 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 Crunch Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Crunch 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 Crunch Project: * Brock Noland br...@apache.org * Christian Tzolov tzo...@apache.org * Gabriel Reid gr...@apache.org * Josh Wills jwi...@apache.org * Kiyan Ahmadizadeh ki...@apache.org * Matthias Friedrich m...@apache.org * Rahul Sharma rsha...@apache.org * Robert Chu robert...@apache.org * Tom White tomwh...@apache.org * Vinod Kumar Vavilapalli vino...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Josh Wills be appointed to the office of Vice President, Apache Crunch, 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 Crunch 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 Crunch Project; and be it further RESOLVED, that the Apache Crunch Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Crunch podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Crunch podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Open Climate Workbench
Hi All, Thanks for the community feedback so far. Since conversation is stabilizing, I am going to call for an official VOTE starting on Monday early AM PT. I'll let it run through the whole week, closing it around Friday EOD PT, and then we can go from there depending on the outcome. Thank you and have a great weekend. Cheers, Chris On 1/26/13 11:48 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal The project is a distributed, scalable approach for the rapid comparison of remote sensing data (e.g., from NASA) with that of climate model output generated by major US and international activities including the US National Climate Assessment, the Coordinated Regional Downscaling Experiment (CORDEX), the North American Regional Climate Change Assessment Program (NARCCAP) the Intergovernmental Panel on Climate Change (IPCC). Much of the software to be donated and evolved here at Apache as a community includes core dependencies to several Apache projects (OODT, Hadoop/HIVE, Sqoop, Tika), and to several key toolkits in the Python software community including NumPy, SciPy, Matplotlib, NCAR NCL, etc. We welcome your feedback over the next week or so for discussion and look forward to it! Cheers, Chris Mattmann Proposed Mentor and Champion ---proposal text = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing data grid. The regridded data spatially is then temporally regridded using techniques including seasonal cycle compositing (e.g., all summer months, all Januaries, etc.), or by daily, monthly, etc. The uniform model output and remote sensing data are then analyzed using pluggable metrics, e.g., Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), Bias, and other (possibly user-defined) techniques, computing an analyzed comparison or evaluation. This evaluation is then visualized by plugging in to the NCAR NCL library for producing static plots (histograms, time series, etc.) We also have performed a great deal of work in packaging RCMES to make the system easy to deploy. We have working Virtual Machines (VMWare VMX and Virtual Box OVA compatible formats) and we also have an installer built on Python Buildout (http://buildout.org/) called Easy RCMET for dynamically constructing the RCMET toolkit. RCMES is currently supporting a number of recognized climate projects of (inter-)national significance. In particular, RCMES is supporting the [[http://www.globalchange.gov/what-we-do/assessment|U.S. National Climate Assessment (NCA) activities]] on behalf of NASA's contribution to the NCA; is working with the [[http://www.narccap.ucar.edu/|North American Regional Climate Change Assessment
Re: [DISCUSS] Apache Open Climate Workbench
Dear Nick, Please add yourself to the proposal on the wiki as a mentor and/or PPMC member and committer in the proposal table. I will call a VOTE next week on Monday so if you can do it before then, thanks. Otherwise I'll do it but I don't know your affiliation. Cheers, Chris On 1/27/13 10:34 PM, Nick Kew n...@apache.org wrote: On 26 Jan 2013, at 19:48, Mattmann, Chris A (388J) wrote: Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal Sounds quite exciting! I'd like to come on board, though whether as an active participant or passively will depend on time and circumstance. Some years back I spent a lot of timeeffort on the somewhat-related task of developing systems, firstly to produce, archive and distribute some of the datasets (mostly the Global AVHRR 1Km series in the '90s) and secondly to develop tools to visualise different datasets alongside and superimposed on each other. I see your proposal has a slightly different focus (and obviously benefits from a new generation of infrastructure in which a terabyte is no longer a mindblowing amount of data to manage), but I hope my background might still serve to kick-start an involvement! -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mentor commitment check?
Hey Benson, Here's one from me -- Apache Climate Toolkit -- am on board and here. Cheers, Chris On 1/30/13 12:51 AM, Benson Margulies bimargul...@gmail.com wrote: Since we have some new proposals in flight, I was wondering about finding some polite way to ask proposed champions and mentors about their level of time commitment. Obviously, no one can see the future, but it might be good to make sure that, at least to start with, the people who are signing up are, in fact, prepared to keep up. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Open Climate Workbench
Dear Nick, On 1/27/13 10:34 PM, Nick Kew n...@apache.org wrote: On 26 Jan 2013, at 19:48, Mattmann, Chris A (388J) wrote: Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal Sounds quite exciting! I'd like to come on board, though whether as an active participant or passively will depend on time and circumstance. You are welcome to join and we'd be happy to have you as a mentor, a PPMC member, or a committer. Your wisdom will be great. Some years back I spent a lot of timeeffort on the somewhat-related task of developing systems, firstly to produce, archive and distribute some of the datasets (mostly the Global AVHRR 1Km series in the '90s) and secondly to develop tools to visualise different datasets alongside and superimposed on each other. Awesome, so you were dealing with remote sensing stuff there, cool. I see your proposal has a slightly different focus (and obviously benefits from a new generation of infrastructure in which a terabyte is no longer a mindblowing amount of data to manage), but I hope my background might still serve to kick-start an involvement! Yep that would be awesome welcome aboard! Cheers, Chris -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Open Climate Workbench
Hey Suresh, Thanks a ton man and great to hear! To your comment below: On 1/27/13 5:56 AM, Suresh Marru sma...@apache.org wrote: Hi Chris, Great proposal, I am personally looking forward to see more of these federal government and international collaboration efforts adopt open community process. Impressive to see this project is pulling together initial developers from government and universities of US, South Africa, UK, Germany and India (I will hope all of them will be able to get their CLA's cleared). You are really scraping the black ice on bureaucratic highways and preventing at least some reinventing wheels with valuable tax payers money in multiple countries. Will this system evaluate and be inclusive of the community earth system modeling community? Yep this proposal includes some of those that are directly involved in that community including Tsengdar Lee, as well as members of the Earth System Grid Federation. We will definitely be inclusive and are happy to have involvement. Thanks! Cheers, Chris Suresh On Jan 26, 2013, at 2:48 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal The project is a distributed, scalable approach for the rapid comparison of remote sensing data (e.g., from NASA) with that of climate model output generated by major US and international activities including the US National Climate Assessment, the Coordinated Regional Downscaling Experiment (CORDEX), the North American Regional Climate Change Assessment Program (NARCCAP) the Intergovernmental Panel on Climate Change (IPCC). Much of the software to be donated and evolved here at Apache as a community includes core dependencies to several Apache projects (OODT, Hadoop/HIVE, Sqoop, Tika), and to several key toolkits in the Python software community including NumPy, SciPy, Matplotlib, NCAR NCL, etc. We welcome your feedback over the next week or so for discussion and look forward to it! Cheers, Chris Mattmann Proposed Mentor and Champion ---proposal text = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing data grid. The regridded data spatially is then temporally regridded using techniques including seasonal cycle compositing (e.g., all summer months, all Januaries, etc.), or by daily, monthly, etc. The uniform model output and remote sensing data are then analyzed using pluggable metrics, e.g., Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), Bias, and other (possibly user-defined) techniques, computing an analyzed comparison or evaluation. This evaluation is then visualized by plugging in to the NCAR NCL library
Re: [DISCUSS] Apache Open Climate Workbench
Hi Suresh, We would be honored to have you on board. Thank you and I'm looking forward to your help and guidance! Cheers, Chris P.S. Add yourself to the wiki, no problem! On 1/27/13 4:36 PM, Suresh Marru sma...@apache.org wrote: On Jan 27, 2013, at 1:56 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Suresh, Thanks a ton man and great to hear! To your comment below: On 1/27/13 5:56 AM, Suresh Marru sma...@apache.org wrote: Hi Chris, Great proposal, I am personally looking forward to see more of these federal government and international collaboration efforts adopt open community process. Impressive to see this project is pulling together initial developers from government and universities of US, South Africa, UK, Germany and India (I will hope all of them will be able to get their CLA's cleared). You are really scraping the black ice on bureaucratic highways and preventing at least some reinventing wheels with valuable tax payers money in multiple countries. Will this system evaluate and be inclusive of the community earth system modeling community? Yep this proposal includes some of those that are directly involved in that community including Tsengdar Lee, as well as members of the Earth System Grid Federation. We will definitely be inclusive and are happy to have involvement. Sounds very good. I am unable to resist my itch, so will like to jump on the band wagon as a committer. Please let me know if I can add myself to the proposal wiki. Thanks, Suresh Thanks! Cheers, Chris Suresh On Jan 26, 2013, at 2:48 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal The project is a distributed, scalable approach for the rapid comparison of remote sensing data (e.g., from NASA) with that of climate model output generated by major US and international activities including the US National Climate Assessment, the Coordinated Regional Downscaling Experiment (CORDEX), the North American Regional Climate Change Assessment Program (NARCCAP) the Intergovernmental Panel on Climate Change (IPCC). Much of the software to be donated and evolved here at Apache as a community includes core dependencies to several Apache projects (OODT, Hadoop/HIVE, Sqoop, Tika), and to several key toolkits in the Python software community including NumPy, SciPy, Matplotlib, NCAR NCL, etc. We welcome your feedback over the next week or so for discussion and look forward to it! Cheers, Chris Mattmann Proposed Mentor and Champion ---proposal text = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing
[DISCUSS] Apache Open Climate Workbench
Hi Everyone! I bring to the Incubator a new proposal for the Apache Open Climate Workbench (incubating) project. I've added the proposal to the Incubator wiki here: http://wiki.apache.org/incubator/ClimateProposal The project is a distributed, scalable approach for the rapid comparison of remote sensing data (e.g., from NASA) with that of climate model output generated by major US and international activities including the US National Climate Assessment, the Coordinated Regional Downscaling Experiment (CORDEX), the North American Regional Climate Change Assessment Program (NARCCAP) the Intergovernmental Panel on Climate Change (IPCC). Much of the software to be donated and evolved here at Apache as a community includes core dependencies to several Apache projects (OODT, Hadoop/HIVE, Sqoop, Tika), and to several key toolkits in the Python software community including NumPy, SciPy, Matplotlib, NCAR NCL, etc. We welcome your feedback over the next week or so for discussion and look forward to it! Cheers, Chris Mattmann Proposed Mentor and Champion ---proposal text = Apache Open Climate Workbench, tool for scalable comparison of remote sensing observations to climate model outputs, regionally and globally. = === Abstract === The Apache Open Climate Workbench proposal desires to contribute an existing community of software related to the analysis and evaluation of climate models, and related to the use of remote sensing data in that process. Specifically, we will bring a fundamental software toolkit for analysis and evaluation of climate model output against remote sensing data. The toolkit is called the [[http://rcmes.jpl.nasa.gov|Regional Climate Model Evaluation System (RCMES)]]. RCMES provides two fundamental components for the easy, intuitive comparison of climate model output against remote sensing data. The first component called RCMED (for Regional Climate Model Evaluation Database) is a scalable cloud database that decimates remote sensing data and renalysis data related to climate using Apache OODT extractors, Apache Tika, etc. These transformations make traditionally heterogeneous upstream remote sensing data and climate model output homogeneous and unify them into a data point model of the form (lat, lng, time, value, height) on a per parameter basis. Latitude (lat) and Longitude (lng) are in WGS84 format, but can be reformatted on the fly. time is in ISO 8601 format, a string sortable format independent of underlying store. value carries with it units, related to interpretation and height allows for different values for different atmospheric vertical levels. All of RCMES is built on Apache OODT, Apache Sqoop/Apache Hadoop and Apache Hive, along with hooks to PostGIS and MySQL (traditional relational databases). The second component of the system, RCMET (for Regional Climate Model Evaluation Toolkit) provides facilities for connecting to RCMED, dynamically obtaining remote sensing data for a space/time region of interest, grabbing associated model output (that the user brings, or from the Earth System Grid Federation) of the same form, and then regridding the remote sensing data to be on the model output grid, or the model output to be on the remote sensing data grid. The regridded data spatially is then temporally regridded using techniques including seasonal cycle compositing (e.g., all summer months, all Januaries, etc.), or by daily, monthly, etc. The uniform model output and remote sensing data are then analyzed using pluggable metrics, e.g., Probability Distribution Functions (PDFs), Root Mean Squared Error (RMSE), Bias, and other (possibly user-defined) techniques, computing an analyzed comparison or evaluation. This evaluation is then visualized by plugging in to the NCAR NCL library for producing static plots (histograms, time series, etc.) We also have performed a great deal of work in packaging RCMES to make the system easy to deploy. We have working Virtual Machines (VMWare VMX and Virtual Box OVA compatible formats) and we also have an installer built on Python Buildout (http://buildout.org/) called Easy RCMET for dynamically constructing the RCMET toolkit. RCMES is currently supporting a number of recognized climate projects of (inter-)national significance. In particular, RCMES is supporting the [[http://www.globalchange.gov/what-we-do/assessment|U.S. National Climate Assessment (NCA) activities]] on behalf of NASA's contribution to the NCA; is working with the [[http://www.narccap.ucar.edu/|North American Regional Climate Change Assessment Program (NARCCAP)]]; and is also working with the International [[http://wcrp-cordex.ipsl.jussieu.fr/|Coordinated Regional Downscaling Experiment (CORDEX)]]. === Proposal === We propose to transition the RCMES software community, which includes developers of the RCMET and RCMED software, along with users of RCMES in the CORDEX project across a variety of academic institutions, scientists helping to improve the RCMES
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Hi Benson, On 1/24/13 7:23 PM, Benson Margulies bimargul...@gmail.com wrote: It's unfortunate to have this conversation in parallel here and on https://issues.apache.org/jira/browse/LEGAL-157. Also, this thread is a combo of the discussion of ordinary jars-of-classes (where I'd forgotten the policy) and the much more tangled question of models, which is what the JIRA is wrestling with. To answer Ted, I think that Roy might write something like: It's not the mission of the ASF to create complete, end-user-friendly, software products. It's our mission to create open source code. If someone else wants to build up an end-user-friendly aggregation of ASF code and models from bombs of whatever, that's great, and we encourage them. What about Apache OpenOffice? I don't think the above statement is correct or true at all. Apache doesn't care about end user friendly, complete, or whatever words like that. Apache is about building open source software communities. If they are eating the dog food, be it filet mignon, or tuna-based, they are eating the dog food and the Apache I know is happy to have their community here. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Hi Guys, On 1/25/13 10:29 AM, Benson Margulies bimargul...@gmail.com wrote: [...snip...] Sorry, that's really what I meant: to think about that file as to whether it can do any harm and how to determine its safety. I haven't looked at the file, but it sounds like you know it can do harm. Depends on what you mean by 'harm'. A model could exhibit hostile behavior, intentionally giving wrong or biased answers for certain inputs. Some people would call that 'harm'. Others would focus on malware, in which case having the model be a big file of numbers that gets turned into a big array would indeed be defined as harmless. So, this is all conjecture. I don't think either of us are qualified Benson to comment or even remotely suggest the harmful nature, validity, etc., of a medical model, or set of them developed by institutions who have accepted the risk (well beyond the ASF's willing accepted risk, etc., for *software*) of leveraging the model for scientific study and prediction. Those institutions go as high up as the National Institutes of Health, the Department of Health and Human Services, etc., etc. Here's what it boils down to -- I get Roy's point, but does everyone else get Roy's point? Roy isn't going to *sanction* wearing big ASF hat the inclusion of things that the ASF isn't willing to accept risk on. The good news? The ASF is NOT a top down organization it's a bottom up one with minimal centralized oversight. That being said there's a subtle hint Roy's text on record that describes what *individuals* as part of a PMC (who are the ones that *release* the software) are, and are not able to do, and what risk they are and are not able to (implied) take on, and perform, within their community. This isn't the ASF coming top down with a policy (good luck every getting one) -- but it's something that has happened in the past with respect to binary convenience bits that even people like Roy say can go on the server. So, why don't we let this sit for a bit, and cTAKES community (and mentors, please speak up) if we are still wanting to proceed down this path, then let's do so, and I think we're going to be OK. See post from Jukka Zitting and I on cTAKES lists: http://s.apache.org/5aZ Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Hey Benson, I agree with Joe - not sure that your job as Incubator VP is to drop any hammers. The org is fine -- the ticket is opened as you said and no bits (binary or source) have been shipped anywhere yet. Still discussing and talking. My fear though is that the discussing and talking are endless and there is not a top down solution here as I stated before. So I simply suggested to the community to proceed with the option below in your statement that gives you and others fewer qualms. No padded cells for you! Cheers, Chris On 1/25/13 12:55 PM, Benson Margulies bimargul...@gmail.com wrote: Chris et al, I'm suffering from a mild crisis of responsibility here. I'm the VP of the incubator. cTakes is planning to ship a release containing something that, according to some lights, is inadmissible. If that 'something' is in *the (source) release*, I have serious qualms. If it's merely in a the convenience binaries, I have fewer. We have a ticket open at LEGAL, and no response except postings of opinion. So, am I supposed to drop a hammer here, required to drop a hammer here, or am I having an acute Alexander Haig moment by even considering dropping a hammer here? I know that a number of board members read this list, so perhaps one or more will tell me which padded cell I should retire to. --benson - 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: Incubator voting status page
Great job, Brane! On 1/24/13 3:50 AM, Joachim Dreimann joachim.dreim...@wandisco.com wrote: Good work Brane. Just one feature suggestion: Could you display the relative time (ie '3 days ago') in the table, and the absolute time in tooltips? That would make it much easier to read I reckon. Cheers, Joe On 24 January 2013 04:05, Branko Čibej br...@apache.org wrote: A while ago I proposed we should have a status page showing current pending votes. To this end I've begun writing a simple script that parses the general@incubator Atom feed from Markmail and creates a static web page with information gleaned from there (it keeps longer-term data in a SQLite database). The script is here: https://svn.apache.org/repos/asf/incubator/public/trunk/incuvoter and the current results are here: http://people.apache.org/~brane/incubator-votes.html That page (should) get updated every 4 hours. It will also list closed votes up to 30 days old. There are currently no links to the actual vote threads. Also I'm having a bit of trouble with the feed from mod_mbox, as it's quite short-term and doesn't seem to be at all complete; that's why I switched to using the current month's worth of data from Markmail. Eventually I'd like to integrate this into the incubator pages, and add logic to the scripts so they'd yell at general@incubator if votes are overdue. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Joe Dreimann UX Designer | WANdisco http://www.wandisco.com/ * * *Transform your software development department. Register for a free SVN HealthCheck http://go.wandisco.com/HealthCheck-Sig.html * - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
+1 this sounds great to me, too. Cheers, Chris On 1/24/13 3:08 PM, Chris Douglas cdoug...@apache.org wrote: On Wed, Jan 23, 2013 at 7:36 AM, Masanz, James J. masanz.ja...@mayo.edu wrote: One goal is to have a binary that contains all resources, which can be used to install cTAKES on a system that does not have an internet connection. For now we can focus on a first Apache release that doesn't meet that goal, while pursuing the question with legal. If legal says we can't do have that kind of binary here, then in the future we can consider if we will host such a binary on a different site. +1 This sounds like a good plan. -C -Original Message- From: general-return-39351-Masanz.James=mayo@incubator.apache.org [mailto:general-return-39351-Masanz.James=mayo@incubator.apache.org] On Behalf Of Chris Douglas Sent: Wednesday, January 23, 2013 3:45 AM To: general@incubator.apache.org Cc: ctakes-...@incubator.apache.org Subject: Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release On Wed, Jan 23, 2013 at 12:47 AM, Jörn Kottmann kottm...@gmail.com wrote: No, the OpenNLP did not have any discussion about it with legal. We just came to the conclusion that its not worth spending time on these issues, when we can instead produce our own training data which is compatible with the Apache license. Understood. Are the compatible training data synthetic? Would you recommend a similar course here? James, is there a reason the models need to be distributed through Apache? Your time is your own, but going through legal could delay your release. - C - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Hi Guys, On 1/21/13 11:48 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Monday, January 21, 2013, Masanz, James J. wrote: Sorry, I didn't mean for you to have to look through the email archives, tinyurl.com/cTAKES-3-0-0-RC4-RESULT Here is a direct link to the VOTE RESULT for RC4. Thanks, though I saw this result. I was looking for the RC5 email http://s.apache.org/Mmj Pei called the VOTE for RC5 simultaneously to general@ and ctakes-dev I see. I was assuming this was following the normal process: http://incubator.apache.org/guides/releasemanagement.html Maybe we need a convention for noting that the vote is concurrent with the PPMC vote. Please, no more conventions or processes. :) This is pretty common, and has happened in the past. Besides procedural things, and getting you pointers to email threads, etc., what do you think of the release, Matt? Thank you for your review as well. Cheers, Chris Regards, James Masanz -Original Message- From: general-return-39328-Masanz.James=mayo@incubator.apache.orgjavascrip t:; [mailto:general-return-39328-Masanz.James javascript:;= mayo@incubator.apache.org javascript:;] On Behalf Of Matt Franklin Sent: Monday, January 21, 2013 12:38 PM To: general@incubator.apache.org javascript:; Subject: Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release On Mon, Jan 21, 2013 at 10:51 AM, Masanz, James J. masanz.ja...@mayo.edu wrote: The result of the VOTE for 3.0.0-incubating on the dev list is at http://mail-archives.apache.org/mod_mbox/incubator-ctakes-dev/201301.m box/browser I looked through the archives and didn't see a RESULT e-mail that summarizes the PPMC vote result. This e-mail is important, as it notifies everyone in your community, and the IPMC, that the voting period is closed and what the final tally is, without having to dig through the thread. It is possible I missed the e-mail, but that is why we in the IPMC ask for a direct link to the result e-mail. The source artifact can be found in http://people.apache.org/~chenpei/ctakes-3.0.0-incubating/rc5/target/ We vote on the source release. That is the artifact that needs to be linked from the VOTE e-mail. I'll look at the jars and the root NOTICE file. Thanks for your review! -- James Masanz -Original Message- From: general-return-39325-Masanz.James=mayo@incubator.apache.org [mailto:general-return-39325-Masanz.James=mayo.edu@incubator.apache.o rg] On Behalf Of Matt Franklin Sent: Monday, January 21, 2013 7:42 AM To: general@incubator.apache.org Cc: ctakes-...@incubator.apache.org Subject: Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release I have some issues with this release as it currently stands: * Where is the result of the VOTE thread on the dev list? * Where is the source artifact? The artifact linked in the vote thread appears to be your convenience binary release. * There are compiled jars in the source tree. These need to be externalized in some fashion. * There are LICENSE NOTICE files in individual project directories that contain entries that don't appear in the root NOTICE file. If you intend on releasing the subcomponents individually, this makes some sense; but I think that the entries should be merged into the root NOTICE file On Fri, Jan 18, 2013 at 9:39 AM, Coarr, Matt mco...@mitre.org wrote: Hi, we just need one more Incubator PMC vote for cTAKES version 3.0. Matt --- From: Chen, Pei pei.c...@childrens.harvard.edu Subject: Collecting IPMC votes Hi, This is a call for a vote on releasing the following candidate as Apache cTAKES 3.0.0-incubating. This will be our first release. A vote is also held on the developer mailing list: http://mail-archives.apache.org/mod_mbox/incubator-ctakes-dev/20130 1.m box/b rowser For more detailed information on the changes/release notes, please visit: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12 t/a pache -ctakes-3.0.0-incubating-bin.tar.gz.asc /.zip.asc Apache cTAKES' KEYS file, containing the PGP keys used to sign the release: http://svn.apache.org/repos/asf/incubator/ctakes/tags/ctakes-3.0.0- inc ubati ng-rc5/KEYS Please vote on releasing these packages as Apache cTAKES 3.0.0- incubating. The vote is open for at least the next 72 hours. Only votes from Incubator PMC are binding, but folks are welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. [ ] +1 Release the packages as Apache cTAKES 3.0.0-incubating [ ] -1 Do not release the packages because... Thanks! Pei P.S.
Re: [DISCUSS] Expressing priorities about release reviews
I agree with you on this Joe. A lot of times my metric is more responsiveness and participation than in legal/language intricacies. More power to folks who are good at that, it's just not me. Cheers, Chris On 1/12/13 9:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote: One of my long time pet peeves with how we PMC members participate in vetting releases is our penchant for focusing too much on the policies surrounding license and notice info. I really think our exclusive focus on things that really don't pose any organizational risk to either the org nor the project participants serves us well in our other, often unexpressed but far more relevant, goals about encouraging committers to participate in active review of their project's commit activity. Just think about this for a second, what's more likely for people to start suing us over, some bug in the NOTICE file or an undetected backdoor in one of our programs? I am personally far more concerned about the current state of the actual review going on in our podlings than I am about NOTICE minutia. Maybe we should compile some list of which committers are actually subscribed to their project's commit lists? It's crude but it may be useful data to look at to a first order. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
Totally agree, Joe. Cheers, Chris On 1/12/13 9:37 AM, Joe Schaefer joe_schae...@yahoo.com wrote: The thing is, as far as risk management goes, the vetting we do on general@incubator is largely ceremonial. The real responsible review work is done by people who are reviewing commit activity, and it is a shame we don't do a better job of empowering these conscientious reviewers with a binding vote on a release. From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org; Joe Schaefer joe_schae...@yahoo.com Sent: Saturday, January 12, 2013 12:30 PM Subject: Re: [DISCUSS] Expressing priorities about release reviews I agree with you on this Joe. A lot of times my metric is more responsiveness and participation than in legal/language intricacies. More power to folks who are good at that, it's just not me. Cheers, Chris On 1/12/13 9:07 AM, Joe Schaefer joe_schae...@yahoo.com wrote: One of my long time pet peeves with how we PMC members participate in vetting releases is our penchant for focusing too much on the policies surrounding license and notice info. I really think our exclusive focus on things that really don't pose any organizational risk to either the org nor the project participants serves us well in our other, often unexpressed but far more relevant, goals about encouraging committers to participate in active review of their project's commit activity. Just think about this for a second, what's more likely for people to start suing us over, some bug in the NOTICE file or an undetected backdoor in one of our programs? I am personally far more concerned about the current state of the actual review going on in our podlings than I am about NOTICE minutia. Maybe we should compile some list of which committers are actually subscribed to their project's commit lists? It's crude but it may be useful data to look at to a first order. - 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: PPMC versus commiter
I have always recommended PPMC==C on all of my podlings, and was taught about that flat organizational structure when I started to see the light at Apache. 2 Tweets that I truly believe in: https://twitter.com/flamefew/statuses/36352411593351168 https://twitter.com/flamefew/statuses/36352484263858176 Making someone a C without PPMC gives them the power to evolve the code, but not to help make decisions about how can maintain it, or when to release it. Something about that, I just don't find right. Cheers, Chris On 12/19/12 4:43 AM, Benson Margulies bimargul...@gmail.com wrote: A recent vote thread on the private list led Christian Grobmeier to wonder why a podling was simultaneously proposing someone for PPMC and committer status. A few bits of background: 1. TLP's vary in their behavior in this regard. Some maintain a committer!=PMC distinction, and some do not. 2. Historically, podlings have *not* maintained this distinction, but have waited for graduation to sort out the initial PMC members. 3. Legally/organizationally, since PPMC members don't have binding votes, there's not much practical effect of making a distinction. At the end of the day, only Incubator PMC members have binding votes. 4. Christian pointed out that the Open Office podling found the process of sorting out the PMC/committer distinction to be painful. With all respect, I don't see the OO podling as typical. It's sheer size put it in a different category, and I for one do not feel inclined to tell podlings to start keeping PPMC and committer distinct on the basis of that history. - 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: PPMC versus commiter
I was that other mentor...*smile* But the awesome part is that I respect Marvin's opinion, as well as the opinion of others that believe (P)PMC != C. Just not on the projects I will work on :) Cheers, Chris On 12/19/12 5:33 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 19, 2012 at 4:43 AM, Benson Margulies bimargul...@gmail.com wrote: 1. TLP's vary in their behavior in this regard. Some maintain a committer!=PMC distinction, and some do not. With all respect, I don't see the OO podling as typical. It's sheer size put it in a different category, and I for one do not feel inclined to tell podlings to start keeping PPMC and committer distinct on the basis of that history. Both ideologies have passionate adherents. While Lucy was in the Incubator, we had a long debate about this topic with myself as the strongest advocate for one position and one of our Mentors as the strongest advocate for the other. (Lucy uses a Committer/PMC Member split now as a TLP, just as we did while in the Incubator.) The status quo seems to be that podlings tend to inherit their Mentors' beliefs. That may please no one, but I cringe at the thought of trying to resolve this one way or another. Consensus would mean one side losing after a long, bloody battle. 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: PPMC versus commiter
On 12/19/12 8:40 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Wed, Dec 19, 2012 at 5:35 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: ...Making someone a C without PPMC gives them the power to evolve the code, but not to help make decisions about how can maintain it, or when to release it. Something about that, I just don't find right As I said, in general I agree, but as a temporary situation that might allow a project to elect someone as a committer early, while taking a bit more time before granting them PMC power. I wasn't replying directly to you, Bertrand, I was replying in general. That said, and I don't want to take this down a long never ending thread, why separate the power? That seems like an artificial line to me and quite honestly I wouldn't work on a project where you trust me to develop/evolve the code, but don't trust me to release it or judge/elect new folks to help maintain it. If you want to elect someone early, elect them as both, early :) Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: PPMC versus commiter
Is it a fight to state an opinion, when one has already been stated, Marvin? C'mon now. Fair's fair, you already got yours out so I have every right to get mine out. To your point of we shouldn't legislate this across all podlings/projects, +1 to that. To your point of ending this useless thread, +1 to that. Cheers, Chris On 12/19/12 8:38 AM, Marvin Humphrey mar...@rectangular.com wrote: On Wed, Dec 19, 2012 at 8:35 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: I have always recommended PPMC==C on all of my podlings, and was taught about that flat organizational structure when I started to see the light at Apache. Argh, do we really have to have this knock-down drag-out fight again? 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: Hadoop Development Tools
Hi Guys, The website and minimal project status is evolving -- sorry, we're trying to get the project bootstrapped since we just had a mentor change and are trying to find some mentoring resources here to push forward. Roman's been doing great, and Adam has really been doing great being the doer here. Cheers, Chris On 12/5/12 8:35 AM, Roman Shaposhnik r...@apache.org wrote: On Wed, Dec 5, 2012 at 4:36 AM, Benson Margulies bimargul...@gmail.com wrote: Roman, there's still no web page even for minimal project status for Hadoop Development Tools. It would be nice for that to come up (as well as a december report). I'm working with the podding on this. Thanks, Roman. - 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: Advice on inviting Apache insight to NSF SI2 meeting?
Hi Guys, Same goes for Apache OODT -- I think it will be a good tie in. Cheers, Chris On Dec 3, 2012, at 8:25 AM, Suresh Marru wrote: Hi Jim, Its great to hear you will be able me make it. I am sure NSF will greatly appreciate your perspectives. We will be happy to provide a case study from Airavata. Suresh On Dec 3, 2012, at 11:12 AM, Jim Jagielski j...@jagunet.com wrote: I am certainly close, if they think I'd be a suitable person. On Dec 1, 2012, at 10:13 AM, Ross Gardler rgard...@apache.org wrote: Anyone able to help the NSF out at a meeting in DC in Jan? See below for more info. On a personal note I've noticed an increased, and genuine, interest in how to improve the impact of publicly funded research outputs from the NSF in the last couple of years. We are even seeing important components turning up in the Incubator. I hope we can send someone able to help them understand how we do things around here. It's your (US) tax dollars going into this work. I'd normally do this myself but I have a clash on these dates. Let me know privately if you are interested and I'll help you/them figure out who the best fit is. Ross Sent from my tablet -- Forwarded message -- From: James Howison jhowi...@ischool.utexas.edu Date: Nov 30, 2012 9:31 PM Subject: Advice on inviting Apache insight to NSF SI2 meeting? To: Ross Gardler rgard...@apache.org Hi Ross, I'm organizing a panel at an upcoming meeting for the PIs of all the projects funded by the SI2 funding program at the NSF (SI2, or SI^2, is the main Scientific Software funding program at the moment). The panel is going to focus on Software Impact, and I'd like to have someone who can inject an understanding of the importance of community, including Incubator considerations such as non-salaried developers etc. We're also considering adopting the DOAP way of describing the projects and their infrastructure as a way of helping projects and the program overall catalogue their activities. The meeting is in DC in January Jan 17 and half-day 18th. Does anyone from Apache come to mind (including yourself) that would be relevant either with experience in Incubation, or from the DOAP/catalogue. Do you think your experience with SIMAL would be relevant here, might you be interested? Best regards, James Howison -- James Howison Sent with Sparrow (http://www.sparrowmailapp.com/?sig) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Marmotta into the incubator
+1 (binding). Cheers, Chris On Nov 29, 2012, at 3:28 AM, Andy Seaborne wrote: Hi there, Following the discussion thread, here is the formal vote on the Marmotta proposal: Please cast your votes on whether to accept the Apache Marmotta proposal: [ ] +1 Accept Marmotta into the Apache Incubator [ ] +0 Indifferent to the acceptance of Marmotta [ ] -1 Do not accept the Marmotta proposal because ... The vote will be open until at least 23:59 Sunday 2nd December UTC (which is three full days from midnight tonight) Andy http://wiki.apache.org/incubator/MarmottaProposal --- == Abstract Marmotta is a Linked Data platform for industry-strength installations. == Proposal The goal of Apache Marmotta is to provide an open implementation of a Linked Data Platform that can be used, extended, and deployed easily by organizations who want to publish Linked Data or build custom applications on Linked Data. The phrase Linked Data is used here idiosyncratically to refer to a data integration paradigm across the Web. The term was coined by Tim Berners-Lee in 2006, and it is based on four very simple principles which basically describe recommended best practices for exposing, sharing, and connecting pieces of data, information, and knowledge on the Semantic Web using URIs and the RDF technology stack. Therefore Linked Data is about using the Web to connect related data that wasn't previously linked, or using the Web to lower the barriers to linking data currently linked using other methods. Marmotta will follow the core recommendations of the W3C on RDF, SPARQL and Linked Data publishing, particularly the emerging Linked Data Platform (LDP) recommendation. It will also offer extensions for frequently needed additional functionalities like Linked Data Querying, WebID, WebACL, Reasoning, and Versioning. Marmotta aims to cover both, Linked Open Data, as well as Enterprise Linked Data scenarios, providing facilities to deal with different data sources and requirements (small data/big data, open access/restricted access, etc). == Background The Semantic Web isn't just about putting data on the web. It is about making links, so that a person or machine can explore the web of data. Moreover, the Web has quickly evolved to a Read-Write paradigm, and Linked Data technologies too. And Marmotta will address this challenge and offer a common infrastructure for organizations working in this area. Marmotta comes as a continuation of the work in the Linked Media Framework (aka LMF) project. LMF is an easy-to-setup server application that bundles central Semantic Web technologies to offer some advanced services. The Linked Media Framework consists of LMF Core which provides a Read-Write Linked Data server, plus some modules that complement the server with other added added capabilities, such as, SPARQL 1.1, LDPath, LDCache, Reasoning, Versioning, etc. Besides, LMF also provides a Client Library, currently available in Java, PHP, and Javascript, as a convenient API abstraction around the LMF web services. Currently LMF integrates with other relevant tools (Apache Stanbol, Google Refine or Drupal) to cover a wider range of use cases and needs. == Rationale Linked Data technologies are now at a turning point from mostly research projects to industrial applications, and a lot of standardisation is currently in progress. Industrial applications require a reliable and scalable infrastructure that follows and helps defining a standard way of publishing and consuming Linked Data on the Web. The proposers have a strong background in building such applications and have invested considerable effort in the last years to building up an initial version of such a platform (the “Linked Media Framework” or “LMF”). Starting from this solid base, we strongly believe that Apache is the right environment to open the development of this project to a wider scope. Marmotta has the potential of being a reference implementation and Apache provides a better environment for a collaborative development effort. With its well-established governance model based on meritocracy and handling IP/legal issues, people from different organizations can more easily contribute to the project. This will help unify the efforts of people implementing the Linked Data Platform specification and other Semantic Web standards. In addition, it would considerably help organizations in adopting Linked Data technologies and would provide a solid base for further research activities in the community. == Initial Goals * Foster the use of Semantic Web Technologies in industry * Provide an open source and community-driven implementation of a Linked Data Platform and related Semantic Web standards, LDP 1.0 Draft and SPARQL 1.1 mainly * Move the existing LMF source from the current Google Code page to
Re: Mentor needed for Hadoop Development Tools
+1 great to hear that you are on board, Suresh. Cheers, Chris On Nov 27, 2012, at 6:08 PM, Adam Berry wrote: Fantastic, thanks for the offer. Could you add your information to the proposal wiki, or go ahead and send it to me and I'll add it. Cheers, Adam On Nov 27, 2012, at 2:41 PM, Suresh Marru wrote: Hi Adam, I am in general interested on the distributed application debugging. I can see some overlap with Airavata project as well. I think I can help out and volunteer to mentor the project. Cheers, Suresh On Nov 27, 2012, at 12:40 PM, Adam Berry ambe...@yahoo-inc.com wrote: Hi IPMC members, we find ourselves in need of an additional mentor for this project, which we are currently in the process of on boarding. You can see the proposal on the wiki at http://wiki.apache.org/incubator/HadoopDevelopmentToolsProposal. Cheers, Adam - 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] Retire Chukwa from incubation
Yeah my sentiments here are of caution -- seems like we need to root out what is going on here based on the community reaction. Cheers, Chris On Nov 26, 2012, at 2:59 AM, ant elder wrote: -1 In the vote on their dev list there wasn't unanimous support for retiring the project, that should be sorted out first before forcibly retiring them and while there are still people who want to give it a go to try to make it work. ...ant On Sun, Nov 25, 2012 at 11:00 PM, Alan Cabrera l...@toolazydogs.com wrote: Hi, The Chukwa community has voted to retire the project. Following the retirement guide [1], I now call the Incubator PMC to vote on confirming this decision. [ ] +1 Retire the Chukwa project [ ] -1 Do not retire the project, because ... [1] http://incubator.apache.org/guides/retirement.html Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What constitute a successful project?
+1 to Jukka's suggestion here. The world isn't going to end if we give them another month, and beyond that, it will give someone besides Eric the opportunity to help cruft the plan (hopefully 2 people besides Eric, since that would mean 3 active peeps in the community). If that plan can't be achieved in a month, I'm +1 to retire. Cheers, Chris On Nov 26, 2012, at 3:21 PM, Jukka Zitting wrote: Hi, On Mon, Nov 26, 2012 at 4:52 PM, Alan Cabrera l...@toolazydogs.com wrote: Even by the PPMC's comments they obliquely acknowledge that there's not much activity and expressed an interested in simply keeping it around with the hopes that something would happen; there were no concrete ideas or plans on how to grow the community because, by their own admission, no one has the time to work much on the project. That lack of concrete plans is a good place to start. Anyone from the community who opposes retirement should take it up on themselves to provide such a concrete plan for example in time for next month's report. Just like the caster of a technical veto should come up with an alternative implementation. :-) As an example of how this can play out, see the way we asked Kitty to provide such a plan [1] when some members of the community opposed the idea of retirement. In Kitty nobody stood up to the task, so a few months later the final decision to retire the project was a pretty easy one to make. Another example with a different outcome is JSPWiki that had a similar discussion at the beginning of the year, and actually a few members of the community did start working through all the issues and have now produced their first Apache release and seem to be on a path towards graduation even though the project is still far below its past activity. [1] http://markmail.org/message/smhl3cxvrgq5cf22 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What constitute a successful project?
Alan, +1 from me. Cheers, Chris On Nov 26, 2012, at 10:32 PM, Alan Cabrera wrote: If we decide to give the podling another chance I would prefer to give it another six months rather than just one month. I don't think that a lot can reasonably be accomplished in one month. I would also like to see some milestones set in those six months. If the milestones are met or not met then the decision at the end of six months will be less contentious. Thoughts? Regards, Alan On Nov 26, 2012, at 4:39 PM, Mattmann, Chris A (388J) wrote: +1 to Jukka's suggestion here. The world isn't going to end if we give them another month, and beyond that, it will give someone besides Eric the opportunity to help cruft the plan (hopefully 2 people besides Eric, since that would mean 3 active peeps in the community). If that plan can't be achieved in a month, I'm +1 to retire. Cheers, Chris On Nov 26, 2012, at 3:21 PM, Jukka Zitting wrote: Hi, On Mon, Nov 26, 2012 at 4:52 PM, Alan Cabrera l...@toolazydogs.com wrote: Even by the PPMC's comments they obliquely acknowledge that there's not much activity and expressed an interested in simply keeping it around with the hopes that something would happen; there were no concrete ideas or plans on how to grow the community because, by their own admission, no one has the time to work much on the project. That lack of concrete plans is a good place to start. Anyone from the community who opposes retirement should take it up on themselves to provide such a concrete plan for example in time for next month's report. Just like the caster of a technical veto should come up with an alternative implementation. :-) As an example of how this can play out, see the way we asked Kitty to provide such a plan [1] when some members of the community opposed the idea of retirement. In Kitty nobody stood up to the task, so a few months later the final decision to retire the project was a pretty easy one to make. Another example with a different outcome is JSPWiki that had a similar discussion at the beginning of the year, and actually a few members of the community did start working through all the issues and have now produced their first Apache release and seem to be on a path towards graduation even though the project is still far below its past activity. [1] http://markmail.org/message/smhl3cxvrgq5cf22 BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Flex podling from Apache Incubator
+1 (binding). Great job, and good luck! Cheers, Chris On Nov 21, 2012, at 11:03 PM, Alex Harui wrote: This is a call for vote to graduate the Apache Flex podling from Apache Incubator. Apache Flex entered the Incubator in December of 2011. We have made significant progress with the project since moving over to Apache. We have 34 committers listed on our status page at [1] including 6 accepted after the podling was formed. Another 5 committers were recently approved after we started the vote to graduate and are not yet listed on the status page. We completed two releases (Apache Flex 4.8.0-incubating and Apache Flex SDK Installer 1.0.9-incubating). The community of Apache Flex is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. The Apache Flex community voted overwhelmingly to graduate [2]. You can view the discussion at [3]. We have prepared and reviewed our charter. You can view it at [4]. Please cast your votes: [ ] +1 Graduate Apache Flex podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Apache Flex podling [ ] -1 Reject graduation of Apache Flex podling from Apache Incubator because ... This vote will be open for at least 72 hours. [1] http://incubator.apache.org/projects/flex [2] http://markmail.org/message/ps3rjgv76vlw4sh5 [3] http://markmail.org/thread/ej4z47rr3ba532uv [4] https://cwiki.apache.org/confluence/display/FLEX/Graduation+Resolution -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - 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: Sub-projects - when are they acceptable? (was Re: [VOTE] Graduate Nuvem as a sub-project under Apache Tuscany)
Fromt he peanut gallery of someone who has participated in a number of sub-projects over the years (Nutch, Tika, Solr, Hadoop, etc.): I don't think they have a big place at the ASF. The word project implies community. Sub communities == umbrella projects == pain, and suffering. OTOH, sub-products, or the ability for a PMC to release multiple products, like e.g., like Lucene does now (Lucene-Java is a product; Solr is a product; PyLucene is a product), that works b/c the sets of individuals that make up those interested in the sub products are not separate communities, they just release different portions of the software that they scratch their itch on. My 2c. Cheers, Chris On Nov 20, 2012, at 3:28 AM, Ross Gardler wrote: On 20 November 2012 11:18, Benson Margulies bimargul...@gmail.com wrote: On Tue, Nov 20, 2012 at 3:01 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Nov 20, 2012 at 6:41 AM, Luciano Resende luckbr1...@gmail.com wrote: ...Nuvem has a great synergy with Apache Tuscany, and after discussion between the two projects, we are seeking IPMC approval to allow graduation of Apache Nuvem as a sub-project under Apache Tuscany Can you clarify what this means? Do all members of the Nuvem PPMC become Tuscany PMC members? Bertrand, this is a great opportunity to clarify the board's attitude toward 'subprojects'. Ever since the campaign to dismantle umbrellas, I've been confused about what structures the board would find reasonable. I don't speak for the board, but my opinion is that if a sub-project is OK as long as it is actively managed by the same PMC as the parent project. Where I start to get worried is when a sub-project takes on a life of its own and significant portions of the parent PMC are not interested in the sub-project and thus fail to provide appropriate oversight. The more sub-projects there are in a project the more likely this is to happen. I'm interested to hear if this is also the opinion of others and thus I've changed the subject. In terms of Nuvem I'm interested in the answer to Bertrands question. Ross - 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: [PROPOSAL] Apache Linda
Hi Guys, This sounds really interesting looking forward to hanging around and see what comes of it! Cheers, Chris On Nov 16, 2012, at 9:14 AM, Sebastian Schaffert wrote: Dear all, we would like to propose a new project called Apache Linda as a Linked Data Platform implementation to the incubator. Andy Seaborne was so kind as to volunteer as a champion for the project. The proposal is available at http://wiki.apache.org/incubator/LindaProposal The goal of Apache Linda is to provide an open implementation of a Linked Data Platform that can be used, extended, and deployed easily by organizations who want to publish Linked Data or build custom applications on Linked Data. Linda will follow the core recommendations of the W3C on RDF, SPARQL and Linked Data publishing, particularly the emerging Linked Data Platform (LDP) recommendation. It will also offer extensions for frequently needed additional functionalities like Linked Data Querying, WebID, WebACL, Reasoning, and Versioning. Linda aims to cover both, Linked Open Data, as well as Enterprise Linked Data scenarios, providing facilities to deal with different data sources and requirements (small data/big data, open access/restricted access, etc). We are looking forward to your feedback and suggestions on how to improve the proposal and idea! Sergio, Thomas, Jakob and Sebastian -- | Dr. Sebastian Schaffert sebastian.schaff...@salzburgresearch.at | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Head of Knowledge and Media Technologies Group +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][PROPOSAL] Hadoop Development Tools
+1 binding. Cheers, Chris On Nov 7, 2012, at 4:57 AM, Adam Berry wrote: Hello, This proposal has been open for discussion for a a few weeks, so now submitting for a vote for this project to be accepted into the incubator. Cheers, Adam Berry = HDT (Hadoop Development Tools) = == Abstract == Tools to support developing applications that use Apache Hadoop from within Eclipse. == Proposal == Hadoop Development Tools are a set of extensions to Eclipse providing support for creating, launching and debugging distributed applications, as well as interacting with HDFS filesystems. This work will build on the existing Map Reduce Tools present in the Apache Hadoop project. == Background == Map Reduce Tools have existed as part of contrib for Apache Hadoop. Unfortunately they are source tied to a single version of Hadoop, and development has stalled, with little movement past the Hadoop 0.20 line. == Rationale == Support for newer versions of Hadoop from within Eclipse is regularly raised on the Hadoop mailing lists, so there is a clear need to drive these tools forward. Development tools generally are worked on separate from the target tools/platform, separating the tools out will allow for supporting multiple versions, so a developer could work with a heterogeneous environment. == Initial Goals == * Give the tools project a home of its own. * Port current MapReduce tools feature set to all current release lines of Hadoop in a single Eclipse install. * Documentation and tutorials for all features. * Publish Eclipse update site, and join Eclipse marketplace listing. * Establish release cycle that combines support for Hadoop and Eclipse release cycles. * Look to build support for YARN, MRUnit and possibly other Hadoop-related projects. == Current Status == The source for the current MapReduceTools lives in the contrib section of the Hadoop source. In its current implementation it is tied to the version of Hadoop against which it is compiled. The layout and API that it was developed with means that it can only be used with the 0.20 or 1.0 Hadoop releases, the new layout and YARN api introduced with the 0.23 and 2.0 lines are not supported. === Meritocracy === Several people and companies have already expressed an interest in contributing to this project, and we hope to attract additional interest during the proposal discussion. We plan to invest and support a meritocracy that attracts, invites, and supports newcomers to build a vibrant and diverse community. === Community === The target community is developers who are working developing Map/Reduce applications against Hadoop. Given the success of Hadoop the target group is likely to be quite large. Separation from the Hadoop community would make it easier to support multiple versions of hadoop, as well as merging the release cycles of Hadoop and Eclipse to provide predictable iteration and improvement in the toolset. === Core Developers === The initial list of developers includes people experienced with Hadoop and developing against the Eclipse platform. * Adam Berry (amberry at yahoo-inc dot com) * Jeffrey Zemerick (jeffrrey at mtnfog dot com) * Evert Lammerts (Evert dot Lammerts at sara dot nl) * Simone Gianni (simoneg at apache dot org) === Alignment === Hadoop Development Tools aligns with both Hadoop and Eclipse. Hadoop as the platform for the development target, and Eclipse as the IDE platform used as the base for the tools. == Known Risks == === Orphaned Products === === Inexperience with Open Source === The committers have experience with Apache and Eclipse open source development. === Reliance on Salaried Developers === Hadoop Development Tools will be developed with a mix of salaried and volunteer time. === Relationships with Other Apache Projects === Hadoop Development Tools is closely related to Apache Hadoop. === An Excessive Fascination with the Apache Brand === Given the success of Hadoop and associated projects, Apache is the natural place for the Hadoop Development Tools. Chris Mattman suggested the Apache Incubator as appropriate on the Hadoop general mailing list following the success that MRUnit had taking the path from Hadoop contrib to an Apache top level project. == Documentation == Documentation for the current tools can be found at http://wiki.apache.org/hadoop/EclipsePlugIn == Initial Source == http://svn.apache.org/repos/asf/hadoop/common/trunk/hadoop-mapreduce-project/src/contrib/eclipse-plugin/ == Source and Intellectual Property Submission Plan == The source, and any suggested initial patches, are already hosted either in Apache’s Subversion or JIRA. == External Dependencies == Eclipse Platform Eclipse Java Development Tools == Cryptography == Hadoop Development Tools likely does not fall into this area. == Required Resources == === Mailing
[ANNOUNCE] Welcome Roman Shaposhnik to the Apache Incubator PMC
Hey Folks, The Apache Incubator PMC has VOTEd to add Roman Shaposhnik to our ranks. Welcome, Roman! Feel free to say a bit about yourself. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [PROPOSAL] Hadoop Development Tools
+1 to giving it a chance at Apache. I'm not sure what Extras buys this effort and I for one am not really interested in helping it there but am sincerely willing to try while it's at the ASF. Cheers, Chris On Oct 18, 2012, at 12:57 PM, Chris Douglas wrote: On Thu, Oct 18, 2012 at 11:56 AM, Jakob Homan jgho...@gmail.com wrote: This seems like it might be more at home at apache-extras. That may ultimately be its fate, but building a community around these tools is worthy of an attempt. This also shares many goals with MRUnit. Collaboration or even merging with that community could also make sense. The code is dead in its current home; letting someone run with it here to see where it leads seems reasonable. On Thu, Oct 18, 2012 at 9:28 AM, Adam Berry ambe...@yahoo-inc.com wrote: I will update the proposal later on to include that, and additionally some idea of how we could support streaming from within the IDE. Seems out of scope. The goal of the project, as I gathered from the proposal, is to produce tools and plugins that complement development of (and on) Hadoop. There's no need to specify which features the community intends to build at this stage. -C Great comments though folks, keep 'em coming! Cheers, Adam On Oct 18, 2012, at 10:53 AM, Simone Gianni wrote: I think it's a good idea, I used the old stuff at the time and it is something that is missing. 2012/10/18 Steve Loughran steve.lough...@gmail.com it may be good to have a proposal that is broader than just eclipse; gives you flexibility in future even if the initial target is the eclipse plugin. Certainly Hadoop Development Tools is pretty broad Steve you are right, but I'm afraid that given how the Eclipse framework requires tight coupling with Eclipse stuff (SWT, workbench system etc..) it's not easy to develop something that can easily be reused on different platforms. However, it could be possible to distribute a stand alone RCP application for those not using Eclipse, and eventually try to implement a generic Hadoop-UI bridge, as far as possible agnostic of specific Eclipse classes and interfaces, that could eventually be reused for other IDEs. Simone - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ${podling}.incubator.apache.org
I would be +1 for simply ${podling}.apache.org, per:
http://wiki.apache.org/incubator/IncubatorDeconstructionProposal
Cheers,
Chris
On Oct 12, 2012, at 12:31 AM, Daniel Shahaf wrote:
Do people mind if web sites (and maybe mailing lists) of new podlings
live at domains of the form ${podling}.incubator.apache.org?
This is in relation to infra work on streamlining TLP migrations. (Case
in point: CMS TLP migrations.) This thread is about the
externally-visible names, not about implementation details.
-
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: ${podling}.incubator.apache.org
I would be +1 for simply ${podling}.apache.org, per:
http://wiki.apache.org/incubator/IncubatorDeconstructionProposal
Cheers,
Chris
On Oct 12, 2012, at 12:31 AM, Daniel Shahaf wrote:
Do people mind if web sites (and maybe mailing lists) of new podlings
live at domains of the form ${podling}.incubator.apache.org?
This is in relation to infra work on streamlining TLP migrations. (Case
in point: CMS TLP migrations.) This thread is about the
externally-visible names, not about implementation details.
-
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] Recommend to the Board to establish the Apache OpenOffice Project
+1 (binding). Good luck Open Office'ers! :) Cheers, Chris On Oct 10, 2012, at 12:00 PM, Andrea Pescetti wrote: Seeing no objections to my last message, and keeping into account that this list had been regularly informed about the steps Apache OpenOffice was taking towards graduation, I'm hereby asking the IPMC to recommend the following resolution to the Board. Aim of the resolution is to establish the Apache OpenOffice Project as a Top Level Project. Please cast your vote: [ ] +1, recommend the resolution to the Board [ ] +0, abstain/don't care [ ] -1, do not recommend the resolution to the Board, because... This vote will be open for 72 hours from now; only votes from the Incubator PMC are binding. Resolution text: --- WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the OpenOffice personal productivity applications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache OpenOffice Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache OpenOffice Project be and hereby is responsible for the creation and maintenance of software related to the OpenOffice personal productivity applications; and be it further RESOLVED, that the office of Vice President, OpenOffice be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache OpenOffice Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenOffice Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache OpenOffice Project: * Andre Fischer (af) * Andrea Pescetti (pescetti) * Andrew Rist (arist) * Ariel Constenla-Haile (arielch) * Armin Le Grand (alg) * Dave Fisher (wave) * Donald Harbison (dpharbison) * Drew Jensen (atjensen) * Ian Lynch (ingotian) * Jürgen Schmidt (jsc) * Kay Schenk (kschenk) * Kazunari Hirano (khirano) * Louis Suarez-Potts (louis) * Marcus Lange (marcus) * Oliver-Rainer Wittmann (orw) * Pedro Giffuni (pfg) * Peter Junge (pj) * Raphael Bircher (rbircher) * Regina Henschel (regina) * RGB.ES (rgb-es) * Roberto Galoppini (galoppini) * Yang Shih-Ching (imacat) * Yong Lin Ma (mayongl) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andrea Pescetti be appointed to the office of Vice President, OpenOffice, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache OpenOffice Project be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the OpenOffice Project; and be it further RESOLVED, that the Apache OpenOffice Project be and hereby is tasked with the migration and rationalization of the Apache OpenOffice.org podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator OpenOffice.org podling encumbered upon the Apache Incubator Project are hereafter discharged. --- Best regards, Andrea Pescetti - Apache OpenOffice PPMC. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New challenges (Was: NOMINATIONS for Incubator PMC Chair)
Hi Benson, Thank you for the kind nomination. I'm not sure I have the time or energy for these duties anymore, plus my goal would still be to retire the Incubator :) and I think the folks around here actually want to see it continue on. If it does continue you, and you're at the helm, I am confident, as I was with Jukka, that I'll be able to work within its system to shepherd in projects from time to time. Thanks! Cheers, Chris On Oct 3, 2012, at 3:40 AM, Benson Margulies wrote: I nominate Chris Mattmann. He's been a positive presence in the incubator for years. It seems to me that the IPMC char has to both guide the work of the group and also channel the Foundation's policies and the board's wants and needs, and he is well-position to do all these things. On Wed, Oct 3, 2012 at 4:09 AM, Dan Haywood d...@haywood-associates.co.uk wrote: On 3 October 2012 07:47, Bertrand Delacretaz bdelacre...@apache.org wrote: Let's fix this: I nominate Benson Margulies as Incubator PMC chair. Benson's been actively involved in the Incubator for quite a while, has mentored several projects, and (despite longish emails sometimes IIRC ;-) has shown great ability to work in a non-confrontational way and help things go forward. I think he'd make a great Incubator PMC chair. +1 on that. Benson has been mentoring the podling I work on (Isis), and I've appreciated his no-nonsense guidance and support. Dan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Graduate Bigtop podling from Apache Incubator
Hi Roman, Great job on this, again. For completeness: On Sep 15, 2012, at 4:08 PM, Roman Shaposhnik wrote: Suresh Marru Is an IPMC member, per [1]. Thanks and again good luck! Cheers, Chris [1] http://people.apache.org/committers-by-project.html#incubator-pmc ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Bigtop podling from Apache Incubator
Super +1. Great work! (binding - especially on the great work part!) :) Cheers, Chris On Sep 12, 2012, at 9:08 AM, Roman Shaposhnik wrote: This is a call for vote to graduate Bigtop podling from Apache Incubator The Apache Bigtop project entered incubator in June of 2011. Since then we have grown the community in users and contributors, and we've made significant improvements to the project. Following the Apache guidelines we have made four releases, we are preparing a 5th major and 6th maintenance releases, and we've added two new committers. The current set of committers and PPMC members are from different organizations and have demonstrated interest in growing the community further. We have learned the basis to manage the different aspects of an Apache project. The community of Bigtop is active, healthy and growing and has demonstrated the ability to self-govern using accepted Apache practices. Bigtop community has voted to proceed with graduation [1] and the result can be found at [2]. Please cast your votes: [ ] +1 Graduate Bigtop podling from Apache Incubator [ ] +0 Indifferent to the graduation status of Bigtop podling [ ] -1 Reject graduation of Bigtop podling from Apache Incubator This vote will remain open for at least 72 hours from now (till 15 Sep 2012, NOON PST). Please find the proposed board resolution below. [1] http://s.apache.org/SGm [2] http://s.apache.org/LOA Thanks, Roman Shaposhnik X. Establish the Apache Bigtop 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 a system for integration, packaging, deployment and validation of a big data management software distribution based on Apache Hadoop 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 Bigtop Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bigtop Project be and hereby is responsible for the creation and maintenance of software related to a system for open-source software related to a system for integration, packaging, deployment and validation of a big data management software distribution based on Apache Hadoop; and be it further RESOLVED, that the office of Vice President, Apache Bigtop 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 Bigtop Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bigtop 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 Bigtop Project: * Alan Gatesga...@apache.org * Patrick Hunt ph...@apache.org * Steve Loughranste...@apache.org * Tom White tomwh...@apache.org * Alejandro Abdelnurt...@apache.org * Andrew Bayer aba...@apache.org * Konstantin Boudnikc...@apache.org * Stephen Chu s...@apache.org * Bruno Mahébm...@apache.org * Peter Linnell plinn...@apache.org * James Pagejamesp...@apache.org * Patrick Taylor Ramsey p...@apache.org * Roman Shaposhnik r...@apache.org * Michael Stack st...@apache.org * Andrei Savu as...@apache.org * Edward J. Yoonedwardy...@apache.org * Andre Arcilla arci...@apache.org * Eli Collins e...@apache.org * Travis Crawford traviscrawf...@apache.org * John Sichij...@apache.org * Owen O'Malley omal...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Roman Shaposhnik be appointed to the office of Vice President, Apache Bigtop, 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 Bigtop 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 Bigtop Project; and be it further RESOLVED, that the Apache
Re: [VOTE] Graduate the Apache SIS podling from the Apache Incubator
Thanks Jukka, I will take your modification into account before pasting into the board agenda. Thanks! Cheers, Chris On Sep 10, 2012, at 12:46 PM, Jukka Zitting wrote: Hi, On Sat, Sep 8, 2012 at 4:42 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Please see the resolution below and VOTE on it for the graduation of the Apache SIS podling from the Apache Incubator. I'll leave the VOTE open for at least 72 hours. [x] +1 Graduate the Apache SIS podling from the Apache Incubator per resolution below. WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to the acquisition, processing, representation, and dissemination of spatial data, The placing of the for distribution at no charge to the public part is a bit unusual, but I can see why having it at the end of the sentence might be a bit confusing. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Graduate the Apache SIS podling from the Apache Incubator
Hi Folks, We are calling the official Incubator VOTE on the graduation of the Apache SIS podling from the Apache Incubator: Community DISCUSS thread here: http://s.apache.org/aqu Community VOTE thread here: http://s.apache.org/I41 Community VOTE result thread here (including 5 IPMC +1s): http://s.apache.org/DGI Please see the resolution below and VOTE on it for the graduation of the Apache SIS podling from the Apache Incubator. I'll leave the VOTE open for at least 72 hours. [ ] +1 Graduate the Apache SIS podling from the Apache Incubator per resolution below. [ ] +0 Don't care. [ ] -1 Don't graduate the Apache SIS podling from the Apache Incubator per resolution below because... Thanks! Cheers, Chris X. Establish the Apache SIS 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, for distribution at no charge to the public, related to the acquisition, processing, representation, and dissemination of spatial data, NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache SIS Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache SIS Project be and hereby is responsible for the creation and maintenance of software related to the acquisition, processing, representation, and dissemination of spatial data and be it further RESOLVED, that the office of Vice President, Apache SIS 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 SIS Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache SIS 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 SIS Project: Adam Estradaaestr...@apache.org Andrew Hart ah...@apache.org Charitha Madusankacharit...@apache.org Martin Desruisseaux desruisse...@apache.org Gregory D. Reddingred...@apache.org Ian Holsman i...@apache.org Joe Schaefer j...@apache.org Kevan Lee Miller ke...@apache.org Chris Mattmann mattm...@apache.org Nga Thien Chung nch...@apache.org Patrick O'Leary pj...@apache.org Peter Karich p...@apache.org Paul Michael Ramirez prami...@apache.org Ross Laidlawrlaid...@apache.org Sean William McCleese smccl...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Adam Estrada be appointed to the office of Vice President, Apache SIS 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 Apache SIS Project be and hereby is tasked with the migration and rationalization of the Apache Incubator SIS podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator SIS podling encumbered upon the Apache Incubator Project are hereafter discharged. ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
