Re: New website to go with new logo?

[Branko Čibej]

On 15.01.2017 15:47, John D. Ament wrote:
> So I want to put this out there as an idea I had been toying with.  With
> our new logo we should launch a new incubator website.  Something more
> modern looking and easier to maintain.  This is in part what I was trying
> to do with the git conversion,


Going slightly on a tangent, /me wonders what bearing the VCS has on how
hard or easy it is to maintain the site content ... let alone how it looks.

Looks like the world has graduated from the "Let's rewrite it in Java"
to the "Let's migrate it to Git" method of wasting time. :)

Always acknowledging, of course, that your time is your own to waste ...
as long as it does not cause everyone else to waste time changing their
tools and workflow. For what good reason, exactly? I must have missed
the well-argued rationale.

-- Brane

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

Re: RTC vs CTR (was: Concerning Sentry...)

[Branko Čibej]

On 18.11.2015 01:35, Konstantin Boudnik wrote:
> On Mon, Nov 16, 2015 at 04:50PM, Greg Stein wrote:
>> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
>>> ...
>>> 1) You're right, I don't trust anybody to make code changes to a complex
>>> project with zero oversight. I currently work on a project that I
>>>
>> I have always found the "complex project" to merely be an excuse for
>> control/no-trust.
>>
>> All software is hard. Your project is no more complex than others.
> +1 on that and what Ralph said. CTR provides a huge stimuli not to
> write-n-push a crappy or semi-baked code. Precisely because of the trust put
> on them by the community of the peers.

The major question here, for me, is: if the project is RTC, then why
would I make an effort to become a committer if at the end of the day
I'm still not trusted to know when to ask for review? It'd be less work
to throw patches at the developers and let them deal with the pain of
reviewing and applying.

How would it feel to get a mail like this:

Congratulations! The developers of Project FOO invite you to become
a committer. All your patches to date have been perfect and your
other contributions outstanding. Of course we still won't let you
commit your changes unless [brass hats] have reviewed and approved
them; we operate by a review-then-commit process. The only real
benefit of committer status is that you can now review other
people's patches and have a binding opinion, unless [brass hats]
have written otherwise in the bylaws.

P.S.: Any competent engineer will immediately see that the optimal
way to proceed is to join an informal group of committers that
mutually +1 each other's patches without unnecessary hassle, and/or
ingratiate yourself with [brass hats] to achieve equivalent results.
After all, it's all about building a healthy community, right?


Betcha there are RTC projects out there that find this satire hauntingly
familiar.


-- Brane


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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Branko Čibej]

On 10.11.2015 16:00, Pierre Smits wrote:
> That is nice! Apache pages drawn up by a member of the Apache Software
> Foundation with the input from many  (both ASF members and others) and
> hosted/communicated through ASF means, and then saying that those 'are not
> Foundation'. And that by/through the fingers of a fellow board member
>
> That doesn't help mitigating the confusion building.

The document is not a Foundation standard. ComDev is no closer to being
"the ASF" than, say, Bloodhound PMC.

Whilst I do find this attempt at a maturity model an interesting
experiment, I'm really, really uncomfortable with people pushing it as
some sort of golden standard for podlings (and, worse, TLPs). It's a
completely informal paper, yet I've already seen people cast doubts on
podling graduation with the excuse that some criterion of the model
wasn't met.

That kind of argument is totally out of line. The IPMC may decide to use
the model as a metric for podling compliance and so integrate it into
the Incubator policy[1]. Unless and until that happens, any attempt to
measure podlings against that bit of paper (other than for purely
recreational purposes) is rude at best.

-- Brane

[1] And even then it'd be open to scrutiny; paperwork for its own sake
is always suspect.


> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Sat, Nov 7, 2015 at 11:04 PM, Greg Stein  wrote:
>
>> On Sat, Nov 7, 2015 at 1:07 PM, Dennis E. Hamilton 
>> wrote:
>>> ...
>>> Huh?  The development of this document,
>>>
>>> <
>> http://community.apache.org/apache-way/apache-project-maturity-model.html
>>> was carried out on the dev community list over a significant period of
>>> time.  It even provides an account for
>>
>> And that is the key part: written by the ComDev community. Not the
>> Foundation. I believe Brane shares my fear that the document will become a
>> de facto standard/requirement across the ASF.
>>
>> Should mentors and podlines want to use it as a guide for things to
>> consider... great.
>>
>> But some of us will push back, if it appears it is being used as a
>> yardstick, rather than a guide.
>>
>> Cheers,
>> -g
>>


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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Branko Čibej]

On 03.11.2015 09:48, Bertrand Delacretaz wrote:
> On Mon, Nov 2, 2015 at 11:11 PM, Joe Brockmeier  wrote:
>> ...Sentry started with 24 committers/PPMC. It hasn't added any PPMC members
>> since its inception...
> If that's correct I'm -1 on graduating Sentry.
>
> and earlier he wrote:
>> ..The model that Sentry is pursing may work very well *for the existing
>> members of the podling.* In my opinion, its process is entirely too
>> opaque to allow for interested parties outside of the existing podling
>> and companies interested in Sentry development to become involved...
> Not having added any PPMC members seems to confirm that.
>
> Based on the information provided in this thread It looks to me like
> Sentry isn't operating according to items CO20, CO40, CS20 and CS50 of
> our maturity model [1].

Can we please stop calling someone's pet paperwork "our maturity model?"
I'm fed up to the gills with the assumption that it has any relevance
for anything or anyone in the foundation, including the Incubator and
Podlings.

-- Brane


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

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 14:05, Pierre Smits wrote:
> Since we're conducting ASF politics here, you're asserting that you're
> corrupt, anti-social and a nutcase?
> And the rest of privileged contributors of the ASF as well?

Are you deliberately misunderstanding what I wrote? If not, I suggest
you go and read it again, it's just a couple sentences after all.

-- Brane

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

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 20:11, Konstantin Boudnik wrote:
> On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
>> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
>>> We should address perceived, and certainly provable, instances of
>>> corruption at the Foundation directly, rather than prescribe policy that
>>> seeks to prevent future instances as if there is a precedent (but there
>>> isn't one here... at least one not spoken aloud, right?).
>> We shouldn't need to have publicly available cases of wrong-doings to
>> say "no wrong-doings please". We hold our politicians to this standard
>> where I come from - it's called the Arm's Length Principle, and it's
>> worked very well.
> But we aren't dealing with politicians here, who are by definition are the
> scam of the earth. So, let's not even get there, please.

"Scam of the Earth" ... one of the better puns I ran into recently. :)

-- Brane

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

Re: [DISCUSS] Mentor neutrality policy

[Branko Čibej]

On 10.10.2015 09:06, Daniel Gruno wrote:
> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
>> We should address perceived, and certainly provable, instances of
>> corruption at the Foundation directly, rather than prescribe policy that
>> seeks to prevent future instances as if there is a precedent (but there
>> isn't one here... at least one not spoken aloud, right?).
> We shouldn't need to have publicly available cases of wrong-doings to
> say "no wrong-doings please". We hold our politicians to this standard
> where I come from - it's called the Arm's Length Principle, and it's
> worked very well.

But the grounds for implementing such a policy are the thousands of
years of history with millions of examples of politicians being
narcissistic, corrupt, anti-social nutcases.

How many examples of corrupt, anti-social nutcases can you count amongst
ASF members or IPMC members, that would justify your proposal?

-- Brane


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

Re: [DISCUSS] Apache Brooklyn graduation as TLP

[Branko Čibej]

On 26.09.2015 14:15, Pierre Smits wrote:
> Why does the pPMC feel the need to aks the board of the ASF to charge the
> TLP to be formed to create set of bylaws?

That's just a clause in the template board resolution proposal; most
podlings don't need it, but also don't trouble to remove it from the
proposed resolution. We've talked about it before on this list. IMO we
should just remove that paragraph from the template.

> If the pPMC feels the need for bylaws, they should work on that during the
> incubation phase and present those to the board for ratification and as
> part of the TLP establisment request.

Stercus bovis. Any (p)PMC can decide to discuss bylaws any time it
likes. And I have to wonder where you got the idea that the Board should
ratify such bylaws.

-- Brane


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

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Branko Čibej]

On 06.09.2015 19:43, Peter Kelly wrote:
> If it’s not possible to write apps using LGPL libraries as part of apache 
> projects,

I expect you did get to read this page:
http://www.apache.org/legal/resolved.html

It explains why we cannot include code under certain libraries in our
releases. It's fine to have optional dependencies on code under one of
these licenses, such that the user can include them when they build
binaries from our sources. But "optional" means that the absence of such
a module doesn't affect the core functionality. If the core
functionality is to be a user interface, then you'd have to find an
appropriately-licenses UI toolkit.

I'm not aware of any such toolkit that's compatible with ALv2 ... which
is a  bit of a pain.


-- Brane

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

Re: apache binary distributions

[Branko Čibej]

On 16.08.2015 21:33, Ted Dunning wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?

 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.


So wait ... If the Subversion PMC releases source, and, say, Debian
creates a binary package called 'subversion-x.y.z' ... you're saying
that's trademark infringement and we should be telling all the people
who produce binary packages to stop using our registered trademark? Really?

Producing binaries is different from creating a derived work. Even if
packagers change the sources (which they often do, in minor ways, to
tune the build to their platform), it's less than sane to tell them they
should rename the packages because of that.

It would be different if their changes resulted in changed
functionality, but that's not what's happening.

-- Brane

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

Re: Reform of Incubator

[Branko Čibej]

On 04.08.2015 18:12, Joe Brockmeier wrote:
 What about the Ignite thread was unfortunate? That it was a bit
 heated at times, or just the fact that there was disagreement? I fear
 that there's too much bias towards +1'ing things even when folks have
 legitimate concerns.


Heated and disagreement are not a problem. The problem I see are all the
people who know nothing about the day-to-day life of the podling, then
start stating conditions for their graduation votes that have nothing to
do with either published ASF policy or published Incubator guidelines.
I'm not going to state names but it's fairly obvious from the archives
who I'm talking about.

This kind of behaviour not only wastes time but puts mentors in an
impossible position: on the one hand, we have to sink a lot of time into
guiding the podling (sometimes with a cluebat), and on the other we have
to defend the podling and our own integrity from the peanut gallery.

No wonder there are never enough active mentors to go around; who in
their right mind would want to spend their free time to go through this
rigmarole twice?

-- Brane


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Branko Čibej]

On 03.08.2015 18:36, Marvin Humphrey wrote:
 It's not the central Incubator folks like our regular release
 reviewers and report contributors who invent these extra criteria

Sorry but this has to be said: I see folks on this list inventing policy
(or rather, confusing opinion and policy) all the time. The Ignite
graduation discussion was a good example of that, but by no means unique.

It's this micromanagement self-preservation reflex (thanks, Roman!) that
puts me squarely on the side of a smaller IPMC that would hopefully also
be less of a peanut gallery. No offence meant and especially not to the
people who do put in a stellar performance hereabouts.

-- Brane


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Branko Čibej]

On 03.08.2015 21:51, Julian Hyde wrote:
 In my experience incubating Calcite, the “overhead” was mostly the 
 infrastructure and process, not politics. (If you think the incubator is 
 political, you haven’t seen politics…) The process is necessary (mostly) to 
 ensure clean IP. The infrastructure, less so. So, if we’re talking about how 
 to reduce the burden on podlings, those are the areas I would focus on.

 Roman’s proposed reform places more responsibility on podling PMCs and, by 
 implication, the mentors embedded in those PMCs.

At the end of the day, it *is* the mentors' responsibility. The IPMC
mostly gets involved after the fact.

 I am not sure how well that would work in practice given the ongoing problem 
 of absentee mentors. The IPMC epitomizes the “it takes a village to raise a 
 child”, in particular with village elders stepping in with help/advice from 
 time to time. It would be a shame to lose that.

There's no need to lose that. But it would be a really good idea to lose
the village spinster who makes the child afraid of the dark and monsters
under the bed ...

-- Brane


 On Aug 3, 2015, at 12:23 PM, Ross Gardler ross.gard...@microsoft.com wrote:

  This is that proverbial political overhead that a lot of folks are 
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is grossly unfair at the board level, but unfortunately seems to be very 
 true at IPMC level today.

 +1000

 -Original Message-
 From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
 Shaposhnik
 Sent: Monday, August 3, 2015 12:13 PM
 To: general@incubator.apache.org
 Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
 Apache Incubator)

 On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
 On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but it 
 seems that nobody has so I'll repeat my question as of a week ago: 
 what would be the effective way to change the status quo around IPMC 
 an make it more board like?

 Perhaps we can start from making the release policy actually make 
 sense along the lines that Ross has outlined. I guess I can propose a 
 change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

 But seriously, who else thinks the movement towards empowering PPMCs 
 and making IPMC very much like the board makes sense?
 I think the thread fizzled because there's not a lot of support for 
 the idea. At least, on my end, I'm not in favor.
 Yup. I believe this to be an unfortunate (at least from my standpoint) but 
 and extremely fair observation.

 As far as I'm concerned the issue of RRs of IPMC is in a state of a 
 stalemate right now. We clearly have a everything's fine lets just add more 
 policy constituency vs. IPMC should be small and more board like crowd.

 The good news is that we're all united on making sure that the foundation is 
 growing by podlings making progress and graduating to TLPs. The bad news is 
 that because of the current mentality I don't see the types of unfortunate 
 threads that Ignite just went through going away anytime soon.

 This is that proverbial political overhead that a lot of folks are 
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is grossly unfair at the board level, but unfortunately seems to be very 
 true at IPMC level today.

 It is clear to me that the change has very little chance of coming from 
 within IPMC.

 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

 -
 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: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 29.07.2015 18:14, Joe Brockmeier wrote:
 On Thu, Jul 23, 2015, at 03:19 AM, Branko Čibej wrote:
 Personally I'm not too happy with how this community tracks issues, but
 hey, if it works for them, why fix it? It'll be a fine day when the IPMC
 starts telling podlings how their development workflow should look like.
 Does works for them translate into people not currently in the
 community can follow how the existing community tracks issues, so they
 can contribute and become part of the community? If so, then maybe it's
 OK. If it's not transparent to folks not currently part of that
 community, it's hard to see how the community will sustain itself with
 new members as other folks inevitably move on to other projects.

Given that new contributors keep showing up on a regular basis, I have
to assume that it's not so opaque as all that.

Anyway, Ignite has been discussing and implementing a revised (and IMO
better) set of policies for Jira use and git workflow since this
discussion started; other than displaying an incomprehensible preference
for RTC, it seems to be going well.

-- Brane


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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 29.07.2015 19:51, Greg Stein wrote:
 On Jul 29, 2015 12:45 PM, Konstantin Boudnik c...@apache.org wrote:
 On Wed, Jul 29, 2015 at 12:25PM, Greg Stein wrote:
 On Jul 29, 2015 11:37 AM, Branko Čibej br...@apache.org wrote:
 On 29.07.2015 18:14, Joe Brockmeier wrote:
 On Thu, Jul 23, 2015, at 03:19 AM, Branko Čibej wrote:
 Personally I'm not too happy with how this community tracks
 issues, but
 hey, if it works for them, why fix it? It'll be a fine day when the
 IPMC
 starts telling podlings how their development workflow should look
 like.
 Does works for them translate into people not currently in the
 community can follow how the existing community tracks issues, so
 they
 can contribute and become part of the community? If so, then maybe
 it's
 OK. If it's not transparent to folks not currently part of that
 community, it's hard to see how the community will sustain itself
 with
 new members as other folks inevitably move on to other projects.
 Given that new contributors keep showing up on a regular basis, I have
 to assume that it's not so opaque as all that.

 Anyway, Ignite has been discussing and implementing a revised (and IMO
 better) set of policies for Jira use and git workflow since this
 discussion started; other than displaying an incomprehensible
 preference
 for RTC, it seems to be going well.
 I always translate RTC as we don't trust you, so somebody else must
 approve anything you do.

 To me, that is a lousy basis for creating a community. Trust and peer
 respect should be the basis, which implies CTR. I have seen many excuses
 for RTC, but they all are just window dressing over mistrust.
 While I tend to agree with you, it worth noting that there's a whole
 bunch of
 TLPs sticking to RTC.  So, this data point doesn't reflect on the podling
 in
 question.
 And POW!! There is one excuse on display already :-P

 But others do it.

How 'bout I propose a board resolution forbidding RTC at the ASF for
mainline development? :)

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 29.07.2015 19:25, Greg Stein wrote:
 On Jul 29, 2015 11:37 AM, Branko Čibej br...@apache.org wrote:
 On 29.07.2015 18:14, Joe Brockmeier wrote:
 On Thu, Jul 23, 2015, at 03:19 AM, Branko Čibej wrote:
 Personally I'm not too happy with how this community tracks issues, but
 hey, if it works for them, why fix it? It'll be a fine day when the
 IPMC
 starts telling podlings how their development workflow should look
 like.
 Does works for them translate into people not currently in the
 community can follow how the existing community tracks issues, so they
 can contribute and become part of the community? If so, then maybe it's
 OK. If it's not transparent to folks not currently part of that
 community, it's hard to see how the community will sustain itself with
 new members as other folks inevitably move on to other projects.
 Given that new contributors keep showing up on a regular basis, I have
 to assume that it's not so opaque as all that.

 Anyway, Ignite has been discussing and implementing a revised (and IMO
 better) set of policies for Jira use and git workflow since this
 discussion started; other than displaying an incomprehensible preference
 for RTC, it seems to be going well.
 I always translate RTC as we don't trust you, so somebody else must
 approve anything you do.

Both Cos and I have been doing our best to explain exactly that to the
podling community. Unfortunately they have bad examples in some very
high profile TLPs, which makes it an uphill battle. It doesn't help that
the Incubator does nothing to promote CTR over RTC.

 To me, that is a lousy basis for creating a community. Trust and peer
 respect should be the basis, which implies CTR. I have seen many excuses
 for RTC, but they all are just window dressing over mistrust.

As far as I'm concerned, RTC == FUD, especially the eff part.

-- Brane

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

Re: [VOTE] Graduate Ignite from the Incubator

[Branko Čibej]

+1 (binding)

On 28.07.2015 22:03, Konstantin Boudnik wrote:
 Following discussions [1],[2] about its current status, the Ignite community
 has voted [3] to graduate from the Incubator. The vote passed [4] with 14
 (non-binding) +1s:

1.  Yakov Zhdanov (PPMC)
2.  Gianfranco Murador (PPMC)
3.  Ira Vasilinets (PPMC)
4.  Nikolai Tichinov (PPMC)
5.  Semyon Boikov (PPMC)
6.  Sergi Vladykin (PPMC)
7.  Alexey Goncharuk (PPMC)
8.  Ognen Duzlevski (PPMC)
9.  Valentin Kulichenko (PPMC)
10. Nikita Ivanov (PPMC)
11. Dmitriy Setrakyan (PPMC)
12. Andrey Novikov (Committer)
13. Alexey Kuznetsov (Committer)
14. Milap Wadwa

 The Ignite community has:
 * completed all required paperwork:
 https://incubator.apache.org/projects/ignite.html
 * completed multiple releases (1.0, 1.1, 1.2, 1.3)
 * completed the name check procedure:
 https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-58
 * opened and worked on 1,150+ JIRAs:
 
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+IGNITE
 * voted in multiple new committers/PPMC members

 Therefore, I'm calling a VOTE to graduate Ignite with the following Board
 resolution. The VOTE will run 72 hours, ending Friday July 31st 2 PM PST.

 [ ] +1 Graduate Apache Ignite from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache Ignite from the Incubator because ...

 Regards,
 Cos

 [1] http://markmail.org/message/5fvca3vr6tkk5q4h
 [2] http://markmail.org/message/uotzsecmwbiuhgjy
 [3] http://markmail.org/message/fzslacsyxlvm3mwm
 [4] http://markmail.org/message/i2mxhgfchlwi34ko

  Apache Ignite graduation resolution draft

 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 delivering an In-Memory Data Fabric - a high-performance, integrated
 and distributed in-memory platform for computing and transacting on
 large-scale data sets in real-time

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

 RESOLVED, that the Apache Ignite Project be and hereby is responsible for
 the creation and maintenance of software related to the automated and
 managed flow of information between systems and be it further

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

 Semyon Boikov (sboi...@apache.org)
 Konstantin Boudnik (c...@apache.org)
 Branko Čibej (br...@apache.org)
 Ognen Duzlevski (mak...@apache.org)
 Sergey Evdokimov (sevdoki...@apache.org)
 Alexey Goncharuk (agoncha...@apache.org)
 Nikita Ivanov (nivano...@apache.org)
 Sergey Khisamov (s...@apache.org)
 Valentin Kulichenko (vkuliche...@apache.org)
 Alexey Kuznetsov (akuznet...@apache.org)
 Gianfranco Murador (mura...@apache.org)
 Andrey Novikov (anovi...@apache.org)
 Vladimir Ozerov (voze...@apache.org)
 Dmitriy Setrakyan (dsetrak...@apache.org)
 Roman Shaposhnik (r...@apache.org)
 Ilya Sterin (iste...@apache.org)
 Nikolai Tikhonov (ntikho...@apache.org)
 Irina Vasilinets (ivasilin...@apache.org)
 Anton Vinogradov (a...@apache.org)
 Sergey Vladykin (svlady...@apache.org)
 Evans Ye (evan...@apache.org)
 Yakov Zhdanov (yzhda...@apache.org)

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

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

 -
 To unsubscribe, e-mail: general-unsubscr

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Branko Čibej]

On 26.07.2015 10:56, jan i wrote:
 On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:

 Hi,

 About 40% of the last 100 threads on general@ is vote release... Cut
 that
 away is a good start in reforming the Incubator…
 IMO Which provides a valuable service in showing poddlings on how to make
 good releases. Do we want to get rid of that?

 No that is an important service, on the other hand I also agree that the
 mentors should be guiding/running the podlings not general@

 Maybe we can find some middle ground.
 - Mentors run the podlings, can accept releases etc.
 - Mentors decide when a podlng can graduate (maybe with some form of, needs
 to accepted by all mentors of the project)
 - Any release must be announced (not voted) on general@, so that people
 like you have a chance of controlling it just like today.

 I think this would make incubator a lot more efficient, reduce our inboxes,
 and give us spare time to concentrate on other things.

I like this proposal very much. One of the constant frustrations in the
podlings I'd mentored was the delay between release bits being ready and
the IPMC getting around to vote. It's now a lot better than it was a
couple years ago, when in some instances it took a month or more ...

Concretely: I think it's perfectly OK to review podling releases after
the fact. The incubation disclaimer tells users clearly enough that they
should be extra careful when using releases from incubating projects.

The other frustration is of course evident in the Ignite graduation
discussion.

The only downside of this proposal is that it assumes that every podling
has at least three active (!) mentors. That doesn't always happen; and
currently we expect the podling to chase down inactive mentors or find
new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
active role in finding mentors for podlings.

Other than that, big +1.

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

 to
the public, related to the automated and managed flow of
information between systems.

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

RESOLVED, that the Apache Ignite Project be and hereby is
responsible for the creation and maintenance of software
related to the automated and managed flow of information
between systems and be it further

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

Semyon Boikov (sboi...@apache.org)
Konstantin Boudnik (c...@apache.org)
Branko Čibej (br...@apache.org)
Ognen Duzlevski (mak...@apache.org)
Sergey Evdokimov (sevdoki...@apache.org)
Alexey Goncharuk (agoncha...@apache.org)
Nikita Ivanov (nivano...@apache.org)
Sergey Khisamov (s...@apache.org)
Valentin Kulichenko (vkuliche...@apache.org)
Alexey Kuznetsov (akuznet...@apache.org)
Gianfranco Murador (mura...@apache.org)
Andrey Novikov (anovi...@apache.org)
Vladimir Ozerov (voze...@apache.org)
Dmitriy Setrakyan (dsetrak...@apache.org)
Roman Shaposhnik (r...@apache.org)
Ilya Sterin (iste...@apache.org)
Nikolai Tikhonov (ntikho...@apache.org)
Irina Vasilinets (ivasilin...@apache.org)
Anton Vinogradov (a...@apache.org)
Sergey Vladykin (svlady...@apache.org)
Evans Ye (evan...@apache.org)
Yakov Zhdanov (yzhda...@apache.org)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that
Dmitriy Setrakyan be appointed to the office of Vice President,
Apache Ignite, 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 Ignite 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 Ignite Project; and be it further

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

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Ignite 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



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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 24.07.2015 00:03, Pierre Smits wrote:
 And we also have keep in mind that the project not only there for those
 with privileges. Focus on that subset of the community isn't building
 healthy, successful projects.

This is the second time on this thread that you've implied that there
are people with inappropriate privileges in the Ignite community. I've
asked you to name specific cases and got no response. If you have
evidence, bring it out. Otherwise stop with these unfounded insinuations.

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 24.07.2015 04:31, Ted Dunning wrote:
 There's a bit of an impedance mismatch here, I agree. I insist that Jira
 is not relevant history.

 You may or may not claim that, but the fact that issue tracking is required
 to be on Apache controlled resources indicates a somewhat different
 result.

Correction: unlike source repositories, issue tracking is not required
to be on Apache controlled resources. There's no policy or bylaw that
requires that. This PMC has graduated at least one podling that doesn't
use an ASF-hosted issue tracker.

-- Brane


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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 23.07.2015 18:26, Ted Dunning wrote:
 On Thu, Jul 23, 2015 at 12:19 AM, Branko Čibej br...@apache.org wrote:

 Concerns have been raised about the people behind the actual commits,
 that
 seems to be left open ?
 I am not sure about this one: why there's a concern that people behind
 commits
 aren't the same ppl as making the fixes? Am I reading this right?
 I think there are a couple things to consider here:

  1. Off-list discussions, and commits made based on such discussions:
 There is absolutely nothing wrong with that. The resultant code is
 public and can be reviewed. If the reasons behind a change are not
 clear, well, it's up to the devs to document the code and/or explain
 on the dev@ list; but forbidding off-list discussions implies
 forbidding hackathons and ApacheCons, for example.

 My question was more to do with losing historical detail by squashing
 commits.  Squashing commits has the tendency to hide contributions as
 well.  I think we have a good answer for that.

I'd rather not state my opinion about squashing commits here; it's not
printable.

 As far as off-list discussions are concerned, this is still a very big
 issue for me.  Off-list discussions and design work is not forbidden, but
 it must be reflected back to the mailing list.

I agree in principle but have to object to the must: it's should.

Obviously it's good practice to post the outcome of offline chats to the
dev@ list for further discussion. On the other hand, I've not seen any
major feature appear in the Ignite code base without dev@ list discussion.

 With Ignite, I worry that such discussions are happening (they must be, by
 geography and time zone alone) but are not being reflected back to the
 mailing list or to the JIRA.  It is not even clear when a bug is closed
 whether there was a code fix or not.

I've put my thoughts on Jira usage into another post.

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 24.07.2015 04:11, Branko Čibej wrote:
 On 24.07.2015 03:41, Daniel Gruno wrote:
 On 07/24/2015 03:22 AM, Branko Čibej wrote:
 On 24.07.2015 01:25, Valentin Kulichenko wrote:
 I do agree that our Jira handling could be better and believe that
 community has already responded to these discussions and addressed some of
 the raised concerns. The truth is that so far many Jira discussions have
 happened on the dev list, including community members sending notifications
 about starting and ending work on Jiras and discussing Jira issues on the
 dev list as well. This was a preferred way selected by the community that
 we followed. I do agree that Jiras should be updated better and will
 encourage everyone to do so going forward.
 As a small reminder, evidently to IPMC members as well as podling
 committers: Jira is not the official archive of what happened on the
 project. Only the dev@ list is. There is no requirement for any project
 to use the ASF Jira instance; there's not even a requirement to use an
 issue tracker. Suddenly making the contents of tickets in Jira an issue
 for graduation is just a bit out of order IMNSHO.

 The important question is whether the development process is open, not
 whether some entries in Jira appear to have adequate comments.
 But, from what I can read in the comments about it, and from what I can
 see when I scan the tickets, lists, commits etc; The commits only refer
 to JIRA tickets and not discussions on the dev list, the JIRA tickets do
 not refer to anything, and the dev list does not refer to neither the
 commits IDs nor the JIRAs...so how exactly are we to interpret what's
 going on then, if it's all suddenly irrelevant?

 Open Source development is not just about publishing your code, it's
 also about making the development and decision process open and
 transparent, and in several cases, such as the ones Ted listed, it does
 not appear to be that way yet.

 I see that this issue has been acknowledged on the dev list by at least
 one member of the project, and while that is a positive response, I
 stand by my decision to withhold support for graduation till I am
 satisfied that this has been shown in a consistent manner across (most
 of) the board.
 There's a bit of an impedance mismatch here, I agree. I insist that Jira
 is not relevant history. Discussions do happen on the dev@ list, so the
 problem must be in the commit messages. I've pointed out that these
 leave much to be desired. My diagnosis here is overuse of Jira; what we
 see here is a typical many-places problem: Discussions happen on the
 dev@ list but a Jira issue is raised for each every change, ever so
 minor; the notification about the issue creation goes to the dev@ list,
 the change is made, nobody objects and that's it. Hence, there doesn't
 seem to be much correlation with all the JIra spam and dev@ discussions.

 First of all, it's not reasonable to expect a dev@ discussion for every
 one-liner change; CTR rules. Next, it's not reasonable to open a Jira
 issue for every one-liner change; that's simply a waste of time (and
 leads to the kind of misunderstandings that we have on this thread).

 I do insist that discussion of important issues and features does happen
 on the dev@ list. The Jira tickets that are created as a result of those
 discussions can easily be cross-referenced by a simple search in the
 dev@ archives.

 My only recommendation here would be to use Jira only to track important
 issues and to always write proper commit logs. The latter is an art that
 takes years to learn ...

And, of course, the overarching question is whether implementing my
recommendation requires hand-holding by the Incubator. I don't think it
does.

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 24.07.2015 01:25, Valentin Kulichenko wrote:
 I do agree that our Jira handling could be better and believe that
 community has already responded to these discussions and addressed some of
 the raised concerns. The truth is that so far many Jira discussions have
 happened on the dev list, including community members sending notifications
 about starting and ending work on Jiras and discussing Jira issues on the
 dev list as well. This was a preferred way selected by the community that
 we followed. I do agree that Jiras should be updated better and will
 encourage everyone to do so going forward.


As a small reminder, evidently to IPMC members as well as podling
committers: Jira is not the official archive of what happened on the
project. Only the dev@ list is. There is no requirement for any project
to use the ASF Jira instance; there's not even a requirement to use an
issue tracker. Suddenly making the contents of tickets in Jira an issue
for graduation is just a bit out of order IMNSHO.

The important question is whether the development process is open, not
whether some entries in Jira appear to have adequate comments.

-- Brane


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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 24.07.2015 03:41, Daniel Gruno wrote:
 On 07/24/2015 03:22 AM, Branko Čibej wrote:
 On 24.07.2015 01:25, Valentin Kulichenko wrote:
 I do agree that our Jira handling could be better and believe that
 community has already responded to these discussions and addressed some of
 the raised concerns. The truth is that so far many Jira discussions have
 happened on the dev list, including community members sending notifications
 about starting and ending work on Jiras and discussing Jira issues on the
 dev list as well. This was a preferred way selected by the community that
 we followed. I do agree that Jiras should be updated better and will
 encourage everyone to do so going forward.

 As a small reminder, evidently to IPMC members as well as podling
 committers: Jira is not the official archive of what happened on the
 project. Only the dev@ list is. There is no requirement for any project
 to use the ASF Jira instance; there's not even a requirement to use an
 issue tracker. Suddenly making the contents of tickets in Jira an issue
 for graduation is just a bit out of order IMNSHO.

 The important question is whether the development process is open, not
 whether some entries in Jira appear to have adequate comments.
 But, from what I can read in the comments about it, and from what I can
 see when I scan the tickets, lists, commits etc; The commits only refer
 to JIRA tickets and not discussions on the dev list, the JIRA tickets do
 not refer to anything, and the dev list does not refer to neither the
 commits IDs nor the JIRAs...so how exactly are we to interpret what's
 going on then, if it's all suddenly irrelevant?

 Open Source development is not just about publishing your code, it's
 also about making the development and decision process open and
 transparent, and in several cases, such as the ones Ted listed, it does
 not appear to be that way yet.

 I see that this issue has been acknowledged on the dev list by at least
 one member of the project, and while that is a positive response, I
 stand by my decision to withhold support for graduation till I am
 satisfied that this has been shown in a consistent manner across (most
 of) the board.

There's a bit of an impedance mismatch here, I agree. I insist that Jira
is not relevant history. Discussions do happen on the dev@ list, so the
problem must be in the commit messages. I've pointed out that these
leave much to be desired. My diagnosis here is overuse of Jira; what we
see here is a typical many-places problem: Discussions happen on the
dev@ list but a Jira issue is raised for each every change, ever so
minor; the notification about the issue creation goes to the dev@ list,
the change is made, nobody objects and that's it. Hence, there doesn't
seem to be much correlation with all the JIra spam and dev@ discussions.

First of all, it's not reasonable to expect a dev@ discussion for every
one-liner change; CTR rules. Next, it's not reasonable to open a Jira
issue for every one-liner change; that's simply a waste of time (and
leads to the kind of misunderstandings that we have on this thread).

I do insist that discussion of important issues and features does happen
on the dev@ list. The Jira tickets that are created as a result of those
discussions can easily be cross-referenced by a simple search in the
dev@ archives.

My only recommendation here would be to use Jira only to track important
issues and to always write proper commit logs. The latter is an art that
takes years to learn ...

-- Brane

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 23.07.2015 23:42, Konstantin Boudnik wrote:
 I think it had more caustic properties. Or the correct spelling is cos'tic?

 I never could tell them apart...

Alright, that's enough. From senseless bean-counting to playground
fights, this thread is becoming a bit off-putting.

-- Brane


 On Thu, Jul 23, 2015 at 11:26PM, Pierre Smits wrote:
 Your comment came across as antagonistic.

 Nuff said.

 Pierre Smits

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

 On Thu, Jul 23, 2015 at 11:23 PM, Konstantin Boudnik c...@apache.org wrote:

 Well, you made a fact-less observation, and I called you on it. How exactly
 is it insulting? Which part of CoC has been violated?

 Cos

 On Thu, Jul 23, 2015 at 11:04PM, Pierre Smits wrote:
 Konstantin,

 Your remark is insulting and uncalled for. Please refrain from such
 actions
 and apply some people skills in line with the code of conduct of the ASF.

 Best regards,

 Pierre Smits

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

 On Thu, Jul 23, 2015 at 8:53 PM, Konstantin Boudnik c...@apache.org
 wrote:
 On Thu, Jul 23, 2015 at 10:16AM, Dmitriy Setrakyan wrote:
 On Thu, Jul 23, 2015 at 6:31 AM, Pierre Smits 
 pierre.sm...@gmail.com
 wrote:

 Apart from the above, the podling could and should do a bit more
 regarding
 building an open, transparent project. Having done a cursory
 review of
 the
 mailing list archives of the podling I have found no announcements
 of
 organisational changes (e.g. adding the new committer/ppmc
 changes/mentor
 changes).

 New committers were announced on the dev list, here is the thread:

 http://apache-ignite-developers.2346864.n4.nabble.com/new-committers-td1221.html
 See the keyword here is 'cursory review' which means glanced at = 4
 message

 Cos


 -
 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: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 23.07.2015 03:11, Konstantin Boudnik wrote:
 On Thu, Jul 23, 2015 at 01:50AM, jan i wrote:
 Concerns have been raised about a off-list issue system, that seems to be
 left open ?
 Concerns have been raised about the people behind the actual commits, that
 seems to be left open ?
 I am not sure about this one: why there's a concern that people behind commits
 aren't the same ppl as making the fixes? Am I reading this right?

I think there are a couple things to consider here:

 1. Off-list discussions, and commits made based on such discussions:
There is absolutely nothing wrong with that. The resultant code is
public and can be reviewed. If the reasons behind a change are not
clear, well, it's up to the devs to document the code and/or explain
on the dev@ list; but forbidding off-list discussions implies
forbidding hackathons and ApacheCons, for example.

 2. Committing changes that were made by someone else: this is
potentially a bit shadier, but in general, the committer is
responsible for the change, not the author. A committer might even
hire someone to develop stuff for them ... that'd be a bit fishy,
but not invalid. The only objection I can think of is if a committer
shares her ASF account with someone else. I've seen no indication of
that happening.


Personally I'm not too happy with how this community tracks issues, but
hey, if it works for them, why fix it? It'll be a fine day when the IPMC
starts telling podlings how their development workflow should look like.

-- Brane


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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 22.07.2015 22:10, Pierre Smits wrote:
 @Branko: are referring to TEZ in your last posting, or Ignite?

I'm a mentor for Ignite; this thread is about Ignite; of course I'm
talking about Ignite.

 If you are talking about ignite, have a look at:
 http://markmail.org/search/incubator.ignite+list:org.apache.ignite.dev and
 http://markmail.org/search/incubator.ignite+list:org.apache.ignite.user and
 check out the 'Who sent it' overviews of each and compare that to the list
 of names (and affiliations). in
 http://ignite.incubator.apache.org/community/resources.html

I frankly don't know what you're talking about. Are you telling me to
review the mailing list traffic and verify that anyone who ever sent a
mail to the lists is mentioned as a contributor? Are you saying that the
correctness of the contributor list is a graduation requirement?


 Then you have the basis for assessing how well the podling has been doing
 the community building aspect and embedding diversity and independence
 during the incubation phase up to now.

Having been a pretty nitpicking mentor, I'm well aware how the community
has been doing, thanks. And I'll restate my opinion that it's been doing
amazingly well. Not only has it gained committers many from outside the
company that donated the code, they've also established working
relationships with other ASF projects that can be integrated with
Ignite. In light of this, anyone who persists in saying that the
community is not open and diverse enough had better come up with some
hard data corroborating that.

-- Brane




 Best regards,

 Pierre Smits

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

 On Wed, Jul 22, 2015 at 9:14 AM, Branko Čibej br...@apache.org wrote:

 On 21.07.2015 21:04, Ted Dunning wrote:
 Actually, given that this project was a spin-out of an internal project,
 this is a stunningly low number to have achieved so quickly (assuming
 that
 the 37% are actually active, that is).
 Indeed. And yes, they're active; that's easily established by reading
 the dev@ list, commit log and Jira log.

 I was quite surprised by how quickly the project got contributors from
 outside, and anyone who takes the trouble to actually look at how the
 community operates will find that it is very helpful and receptive. I
 wouldn't be surprised if there are quite a few TPLs and even recently
 graduated podlings that could take the Ignite community as an example
 rather than the other way around.

 I suggest that everyone who doubts that this is an open and diverse
 community should go and read the mailing list archives for the last few
 months or so instead of making uninformed statements based on some
 incidental numbers. If, on the other hand, you prefer running the IPMC
 using statistics instead of facts, you could at least have made the
 effort to look at the trends instead of a point-in-time snapshot.

 -- Brane


 -
 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: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 21.07.2015 21:04, Ted Dunning wrote:
 Actually, given that this project was a spin-out of an internal project,
 this is a stunningly low number to have achieved so quickly (assuming that
 the 37% are actually active, that is).

Indeed. And yes, they're active; that's easily established by reading
the dev@ list, commit log and Jira log.

I was quite surprised by how quickly the project got contributors from
outside, and anyone who takes the trouble to actually look at how the
community operates will find that it is very helpful and receptive. I
wouldn't be surprised if there are quite a few TPLs and even recently
graduated podlings that could take the Ignite community as an example
rather than the other way around.

I suggest that everyone who doubts that this is an open and diverse
community should go and read the mailing list archives for the last few
months or so instead of making uninformed statements based on some
incidental numbers. If, on the other hand, you prefer running the IPMC
using statistics instead of facts, you could at least have made the
effort to look at the trends instead of a point-in-time snapshot.

-- Brane


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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Branko Čibej]

On 21.07.2015 03:26, Konstantin Boudnik wrote:
 Thanks for kicking off this discussion, Dmirtiy.

 As one of the mentors I think this podling is ready to get graduated. The 
 process of indocrInating this group of people into the Apache Way was not 
 always a walk in a park and we had our share of heated discussions. But the 
 fact that the community converged into the ASF way of doing things and did it 
 with open face makes me believe that the goal of the incubation has been 
 achieved. There's nothing for me as a mentor to help this podling with.

I second all of the above.

 No, scratch that. One last thing I want to do. Here it is: before we submit 
 this resolution to the IPMC vote, let's remove the following paragraph:

 RESOLVED, that the initial Apache Ignite 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 Ignite Project; and be it further

 There's clearly no need to create any special bylaws unless the project needs 
 to amend the common and minimal set of ASF bylaws. Having more laws makes a 
 project worst off not better. Hence, I move to remove this clause completely.

Agreed. The Ignite podling has its development and release processes
adequately documented and/or automated and IMO does not need any further
rules that depart from published ASF policy.

--  Brane

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

Re: [RESULT] [VOTE] Apache Ignite 1.2.0 release (RC2)

[Branko Čibej]

On 29.06.2015 21:42, Pierre Smits wrote:
 Ladies would be even better. :-)

Oh, indeed, but just once I wish I could have a pun go unanswered ... :-P

 Op maandag 29 juni 2015 heeft Branko Čibej br...@apache.org het volgende
 geschreven:

 On 29.06.2015 15:36, Marvin Humphrey wrote:
 On Sun, Jun 28, 2015 at 10:56 PM, Yakov Zhdanov yzhda...@apache.org
 javascript:; wrote:
 Guys,
 It's nice to be informal, but we're not just guys. :)
 Aye; next time, please address mails to laddies and gentlemen. :)

 -- Brane


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




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

Re: [RESULT] [VOTE] Apache Ignite 1.2.0 release (RC2)

[Branko Čibej]

On 29.06.2015 15:36, Marvin Humphrey wrote:
 On Sun, Jun 28, 2015 at 10:56 PM, Yakov Zhdanov yzhda...@apache.org wrote:
 Guys,
 It's nice to be informal, but we're not just guys. :)

Aye; next time, please address mails to laddies and gentlemen. :)

-- Brane


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

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Branko Čibej]

On 25.06.2015 09:17, Jochen Theodorou wrote:
 Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH):
 For HTTPd I was referring to the assertion from Justin earlier in
 this thread  FWIW, httpd always had nightly tarballs available for
 consumption and testing. (though reading that now I wonder if he
 meant source tarballs - which is an easy way of resolving this whole
 issue)

I don't see how that makes anything easier: it doesn't matter if the
package contains source or binaries or pictures of kittens, the only
question is whether it's a release or not.

 nightly source tarballs? Is that really a thing?

Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
yet it can actually run on computers! :)

-- Brane

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

Re: [VOTE] Apache Ignite 1.2.0 release (RC2)

[Branko Čibej]

On 24.06.2015 08:34, Dmitriy Setrakyan wrote:
 On Tue, Jun 23, 2015 at 8:26 AM, Justin Mclean jus...@classsoftware.com
 wrote:

 Hi,

 Moreover, modules under extdata are test only and are not used anywhere
 in
 the project. They are used to test code deployment functionality.
 Perhaps it would be best to make it clearer that they are used for test
 data or better still generate them. Can the files be generated from source?

 Would it be OK for us to proceed with this 1.2.0-incubating release and
 fix
 the issues mentioned in the next release shortly after?
  [1]/[2] The release policy (3.6) is quite clear on this. However if other
 IPMC members vote +1 I’ll consider changing my vote.

 Hi Justin,

 We already have 2 +1 votes from IPMC members:

 - Branko Čibej (binding)
 - Konstantin Boudnik (binding)

FWIW, I agree it would be better to generate these files from source if
possible; however, I don't think it's a showstopper for this release.

-- Brane

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

Re: [VOTE] Apache Ignite 1.2.0 release (RC2)

[Branko Čibej]

On 23.06.2015 17:26, Justin Mclean wrote:
 Hi,

 Moreover, modules under extdata are test only and are not used anywhere in
 the project. They are used to test code deployment functionality.
 Perhaps it would be best to make it clearer that they are used for test data 
 or better still generate them. Can the files be generated from source?

There's nothing wrong with having binary files in a source release, and
some just can't be generated. A trivial example: a bitmap image file.
The fact that a file is binary, no matter what it's used for, can't be
reason for holding back a release.

Subversion, for example, has whole repository snapshots in its test
suite. I've never heard any complaints.

-- Brane


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

Re: [VOTE] Apache Ignite 1.2.0 release (RC2)

[Branko Čibej]

On 23.06.2015 21:14, Branko Čibej wrote:
 The fact that a file is binary, no matter what it's used for, can't be
 reason for holding back a release.

Let me amend that: as long as it doesn't affect the functionality of
the product in any way.

-- Brane

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

Incubator web site not updating?

[Branko Čibej]

I made some updates to the Ignite status page, built the site locally
without errors, checked the updates, committed and published the site
through https://cms.apache.org/incubator/publish .

But the updates aren't showing up on the public site. I don't know where
to look for logs. Any ideas?

-- Brane

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

Re: [VOTE] Release apache-calcite-1.3.0-incubating

[Branko Čibej]

On 27.05.2015 01:40, Julian Hyde wrote:
 Hi all,

 The Calcite community has voted on and approved a proposal to release
 Apache Calcite 1.3.0-incubating.

 Proposal: http://s.apache.org/calcite-1.3-vote

 Vote result: http://s.apache.org/calcite-1.3-result
 4 binding +1 votes
 4 non-binding +1 votes
 No -1 votes

 The commit to be voted upon:
 http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/495f1859f84b41ae70b2099c3d15c696a49a5100

 Its hash is 495f1859f84b41ae70b2099c3d15c696a49a5100.

 The artifacts to be voted on are located here:
 https://dist.apache.org/repos/dist/dev/incubator/calcite/apache-calcite-1.3.0-incubating-rc1

 The hashes of the artifacts are as follows:
 src.tar.gz.md5 1d084f05e11f202f69594152d1771d6d
 src.tar.gz.sha1 e1189cd2de0c6096deac28b3d1a2c9be9bb88d6d
 src.zip.md5 63ea0765b6c872454472e31ac18bc394
 src.zip.sha1 50f90a9f0b700a9617d63ca75687d8717dc4c434

 A staged Maven repository is available for review at:
 https://repository.apache.org/content/repositories/orgapachecalcite-1008

 Release artifacts are signed with the following key:
 https://people.apache.org/keys/committer/jhyde.asc

 Pursuant to the Releases section of the Incubation Policy and with
 the endorsement of 1 of our mentors we would now like to request
 the permission of the Incubator PMC to publish the release. The vote
 is open for 72 hours, or until the necessary number of votes (3 +1)
 is reached.

 [ ] +1 Release this package as Apache Calcite 1.3.0-incubating
 [ ] -1 Do not release this package because...

 Here is my vote:
 +1 (binding)

 And forwarding the votes of two other IPMC members:
 +1 (binding) Alan Gates
 +1 (binding) Jacques Nadeau

 Julian Hyde, on behalf of Apache Calcite PPMC


+1 (binding)

For the next release, please consider fixing the following issues:

1. RAT emits warnings:

Files with unapproved licenses:

  ./git.properties
  ./avatica/src/main/resources/META-INF/services/java.sql.Driver
  ./core/src/main/resources/META-INF/services/java.sql.Driver
  ./example/csv/src/test/resources/bug/DATE.csv
  ./example/csv/src/test/resources/bug/WACKY_COLUMN_NAMES.csv
  ./example/csv/src/test/resources/bug/archers.json
  ./example/csv/src/test/resources/sales/DEPTS.csv

*

Archives:

 + ./example/csv/src/test/resources/sales/EMPS.csv.gz


These are clearly false positives, and I see that the pom.xml file
contains exclusions for these files. I suggest also providing a
rat-excludes file with the same exclusion rules, so that RAT can be run
on the tree without going through maven (and trusting the pom.xml :).

2. The tarball contains the user-specific git.properties file, whereas
the zip file does not. This seems to be a packaging bug.

3. Please use the standard format for .sha1 and .md5 files, as generated
by sha1sum and md5sum; it's really unpleasant to check signatures in
non-standard ways.

-- Brane


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

Re: [VOTE] Apache Ignite 1.1.0 release (RC7)

[Branko Čibej]

On 25.05.2015 12:14, Yakov Zhdanov wrote:
 Hello!

 The Apache Ignite  PPMC has voted to release Apache Ignite 1.1.0-incubating.
 The vote was based on the release candidate and thread described below.
 We now request the IPMC to vote on this release.

 Apache Ignite 1.1.0 release (RC7) has been accepted with 7 votes for (1
 binding vote):

Two binding votes. Mine's binding, too.

 1. Konstantin (binding)
 2. Brane
 3. Yakov
 4. Sergi
 5. Alex Kuznetsov
 6. Vladimir
 7. Valentin

 We have uploaded release candidate to
 https://dist.apache.org/repos/dist/dev/incubator/ignite/1.1.0-rc7

 Tag name is
 ignite-1.1.0-incubating-rc7

 RC7 changes:
 Fixed unexpected LICENSE, NOTICE and DEPENDENCIES files in sources zip.
 Fixed LICENSE, NOTICE files content inside ignite-core jar.
 Binaries names now ends with -bin.
 Aggregate project and all its artifacts names contains apache prefix.
 And many more changes which are described in devnotes (link below).

 DEVNOTES
 https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.1.0-incubating-rc7

 RELEASENOTES
 https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.1.0-incubating-rc7

 Please start voting.

 +1 - to accept Apache Ignite (incubating) 1.1.0
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite (incubating) 1.1.0 (explain why)

 Here is the PPMC vote thread -
 http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-1-0-release-RC7-td618.html

 This vote will go for 72 hours.

 Thanks!

 --Yakov



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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 20.05.2015 03:09, Branko Čibej wrote:
 On 20.05.2015 00:44, Justin Mclean wrote:
 Hi,

 +0 (binding) from me until these 2 issues are resolved. Of course other IPMC 
 members may vote differently.

 Several bundled files have GPL license headers e.g. 
 ./ipc/shmem/config.guess, ./ipc/shmem/ltmain.sh etc. While these look like 
 auto generated build files but I'm not sure that they can be included in a 
 source release.
 There's no way around including such files; any normal (i.e., not Java
 :) source package that uses configure and libtool needs those files
 bundled in the source.

 However, I'll have to vote -1: the LICENSE, NOTICE and DEPENDENCIES
 files shouldn't be in the package. They appear to be some maven side
 effect. Especially LICENSE and NOTICE are confusing because a user has
 no way to be sure which file she should be reading.

 Other issues:

I probably should have said explicitly that these other issues are not
release blockers as far as I'm concerned.

-- Brane


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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 20.05.2015 12:55, Yakov Zhdanov wrote:
   * There are many, many HTML syntax errors in the javadocs.

 YZ: Far from being a serious issue. Javadocs can be built without errors
 and look good in browser. I think this can be addressed with low priority
 in the background.

Well, the maven build spits out around 500 lines of unclosed tag and
other HTML syntax warnings. Of course that could be a side effect of
bugs in javadoc itself.

-- Brane


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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 20.05.2015 12:55, Yakov Zhdanov wrote:
 Brane, given you are busy should we consider extending PPMC vote for 96 hours?

Thanks for the consideration, but those other issues are under control
now; the usual 72 hours will be fine.

-- Brane


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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 19.05.2015 00:42, Justin Mclean wrote:
 Hi,

 In the source reefs eI notice a LICENSE, LICENSE.txt, NOTICE and NOTICE.txt 
 whose contents don’t match each other. I assume the LICENSE.txt and 
 NOTICE.txt are the real files to look at?

Yes. the LICENSE.txt and NOTICE.txt appear to be the real files ... I
have no clue where the .txt-less files came from. They're not in the
tagged tree in the repository.

-- Brane

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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 20.05.2015 00:44, Justin Mclean wrote:
 Hi,

 +0 (binding) from me until these 2 issues are resolved. Of course other IPMC 
 members may vote differently.

 Several bundled files have GPL license headers e.g. ./ipc/shmem/config.guess, 
 ./ipc/shmem/ltmain.sh etc. While these look like auto generated build files 
 but I'm not sure that they can be included in a source release.

 I’m also unable to compile from source:
 [INFO] An Ant BuildException has occured: exec returned: 128
 around Ant part ...exec outputproperty=ignite.build executable=git 
 failonerror=true... @ 20:75 in 
 /Users/justinmclean/Downloads/ApacheIgnite/ignite-1.1.0-incubating-src/modules/core/target/antrun/build-main.xml
 /Users/justinmclean/Downloads/ApacheIgnite/ignite-1.1.0-incubating-src/modules/core/target/antrun/build-main.xml:20:
  exec returned: 128

Actually, the package compiles just fine despite this message. You just
have to wait for ages for Maven to download a zillion JARs, each about 7
times ...

-- Brane

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

Re: [VOTE] Apache Ignite 1.1.0 release (RC5)

[Branko Čibej]

On 20.05.2015 00:44, Justin Mclean wrote:
 Hi,

 +0 (binding) from me until these 2 issues are resolved. Of course other IPMC 
 members may vote differently.

 Several bundled files have GPL license headers e.g. ./ipc/shmem/config.guess, 
 ./ipc/shmem/ltmain.sh etc. While these look like auto generated build files 
 but I'm not sure that they can be included in a source release.

There's no way around including such files; any normal (i.e., not Java
:) source package that uses configure and libtool needs those files
bundled in the source.

However, I'll have to vote -1: the LICENSE, NOTICE and DEPENDENCIES
files shouldn't be in the package. They appear to be some maven side
effect. Especially LICENSE and NOTICE are confusing because a user has
no way to be sure which file she should be reading.

Other issues:

  * The official source for official convenience binaries should be
the source package, not some tag in the repository. The source
package is what we release; not the repository contents. I'm sure I
mentioned that before.
  * I agree with Justin about binary package placing and naming; you'll
recall that I was quite eloquent on that topic a while ago, without
much effect.
  * There are many, many HTML syntax errors in the javadocs.
  * Once finally run, the node says New version is available at
ignite.incubator.apache.org: 1.0.0. Surely that's a bug if I'm
running 1.1.0?

Finally, I apologize for not bringing these issues up on the PPMC vote
thread; I was sidetracked by other issues the last couple weeks.

-- Brane


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

Re: Apache Ignite twitter

[Branko Čibej]

On 22.04.2015 08:04, Andrew Bayer wrote:
 I have to express a concern here - this sort of thing has happened before
 with the same person on a different ASF account. A pattern is forming.

It was not the same person. The only obvious pattern here is Twitter
and I'm not going to repeat my views on that. Please get your facts
straight before randomly accusing people.

-- Brane


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

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Branko Čibej]

On 31.03.2015 16:00, Stian Soiland-Reyes wrote:
 8) It would be good to avoid all those RC RCs as it's confusing to
 have multiple levels of release candidates - in Apache, a Release
 Candidate is this particular thing you are asking us to vote over.
 (this might have been pointed out earlier). A pre-release can be
 called anything else, like alpha, golden master, etc.
 https://www.apache.org/dev/release.html#what

We've been through this and I disagree. Do not confuse release process
with release naming. That page conflates the two, which makes it just a
bit broken IMO. There are no rules for release naming in Apache.

-- Brane


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

Re: [VOTE] Release Apache Ignite (Incubating) 1.0

[Branko Čibej]

On 31.03.2015 17:46, Marvin Humphrey wrote:
 On Tue, Mar 31, 2015 at 7:44 AM, Branko Čibej br...@apache.org wrote:
 On 31.03.2015 16:00, Stian Soiland-Reyes wrote:
 8) It would be good to avoid all those RC RCs as it's confusing to
 have multiple levels of release candidates - in Apache, a Release
 Candidate is this particular thing you are asking us to vote over.
 (this might have been pointed out earlier). A pre-release can be
 called anything else, like alpha, golden master, etc.
 https://www.apache.org/dev/release.html#what
 We've been through this and I disagree. Do not confuse release process
 with release naming. That page conflates the two, which makes it just a
 bit broken IMO. There are no rules for release naming in Apache.
 It would be more apparent that the podling has their release process under
 control if the release-process-candidates being iterated on were clearly
 differentiated using unambiguous directory names, Git tag names, etc.

 For example, the last vote could have been on...

   http://people.apache.org/~dsetrakyan/ignite-1.0.0-RC3-rc2
   GIT tag release-1.0.0-RC3-rc2

 ... and this vote could have been on:

   http://people.apache.org/~dsetrakyan/ignite-1.0.0-rc0
   GIT tag release-1.0.0-rc0

 That's still a little hard to follow, but at least it distinguishes different
 release-process-candidates from each other.

Oh, that's a different matter entirely. Release process needs polishing
and documenting (and scripting and automating), I agree; up to now, it's
been mostly about getting the licensing stuff squared away. One step at
a time. :)

-- Brane


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

Re: junior Mentor request advice from senior Mentor.

[Branko Čibej]

On 22.03.2015 09:05, jan i wrote:
 Hi.

 Sorry could not resist the subject line, but fact is I need a good advice.
 I know our rulebook about including 3rd party libraries, but rules are open
 to interpretation, and since I am involved in the development I consider my
 opinion for biased.

 In Corinthia we depend on the following third party libraries (currently
 not in repo):
 zlib1
 libxml2
 iconv
 SDL
 SDL_Image.

 The first 3 ones are not available precompiled for windows 64bit (at least
 not from a trustworthy source), so we need to make it available.

 I see 3 options:
 1) Ask developers to download and build by them self (sadly enough they
 also need to setup the vcxproj file)
 2) one PPMC (in this case me) precompilles all libs, make them available as
 a zip on minotaur,
 which of course is a trusted source, but somewhat ackward to the project.
 3) the sources are added to the repo, in a designated directory and
 integrated in our build system.

 I would prefer to suggest 3), but I want to be absolutely sure, that we do
 it the right way.
 I would suggest:
 a) put a README, for each downloaded lib, with the original URL and version
 b) add the licenses to the LICENSE file
 c) copy the README into NOTICES
 d) In the first commit, make a commit text like the README.
 e) Make the missing bits for a 64bit version, and integrate in our build
 system.

 Would that be a good solution to the problem, or do you have other ideas or
 corrections ?

 My goal here is, to make the right decision up front, and not when we have
 cut a release.

Write a script that downloads the supported versions and include the
necessary vcxproj files in your source distribution. I believe msbuild
can download stuff, so you may even be able to automate the download
from the project file.

-- Brane

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

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

[Branko Čibej]

On 20.03.2015 21:45, Dmitriy Setrakyan wrote:
 Hello,

 The Apache Ignite PPMC voted to release Apache Ignite (incubating) 1.0 RC3.

 We now request the IPMC to vote on the release.

 Here is the PPMC voting result form Apache Ignite IPMC:

 5 +1 (binding)
 0 = 0 (binding)

 The dev list voting thread:
 http://mail-archives.apache.org/mod_mbox/ignite-dev/201503.mbox/%3CCA+0=VoWWtUj6BUxUxfDN23H2nTm92BXkR_yR4_PMk=vqn2f...@mail.gmail.com%3E

 All release artifacts have been uploaded here:
 http://people.apache.org/~dsetrakyan/ignite-1.0.0-RC3

 Please start voting.

 +1 - to accept Apache Ignite (incubating) 1.0 RC3 release
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite (incubating) 1.0 RC3 release (explain why)

Ping. To make things easier: the podling needs one more IPMC vote for
its first release; the current tally (not counting the RM) is:

+1 Yakov Zhdanov (PPMC)
+1 Sergi Vladykin (PPMC)
+1 Semyon Boikov (PPMC)

and

+1 Konstantin Boudnik (Mentor; binding)
+1 Branko Čibej (Mentor; binding)


-- Brane

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

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

[Branko Čibej]

On 22.03.2015 00:09, Marvin Humphrey wrote:
 On Sat, Mar 21, 2015 at 2:16 AM, Dmitriy Setrakyan
 dsetrak...@apache.org wrote:

 The new 1.0 release with corrected headers will be
 submitted for PPMC vote on Monday.
 Hmm, I'm confused.  This is 1.0-RC3.  I would ordinarily expect that
 to become 1.0 once the release vote succeeds.  While Apache isn't
 going to force a particular versioning scheme on you, I don't think
 you can put out two releases with the same version number.  That would
 result in identically named artifacts with different content and
 security mechanisms going berzerk as a consequence.
 This was intended to be a public RC3 release. If it was to pass the vote,
 then the official release would also have 1.0-RC3 version.

 We wanted to have community to play with the RC3 release for a bit until we
 release the final 1.0 release in a week or two.
 Because release candidate and RC are specialized terms with
 precise meaning at Apache and because we make a strong legal
 distinction between released and unreleased code, this is
 extremely confusing.  Having something named RC which is also an
 official Apache release is... gah, it makes my brain hurt.

 Please consider adopting different terminology in the future --
 alpha, beta, golden master candidate / GM candidate, etc.

Nonsense. Subversion has been making public candidate releases for 1.x.0
for years and we've not seen any of our users' heads explode yet. It's
just like a public beta but with stronger expectations wrt stability.
Release candidate just means we believe it will become 1.0 but we may
still have to tweak it a bit. Our users don't care if there's a
recommended internal process that also mentions 'release candidate' in a
different context.

http://subversion.apache.org/docs/community-guide/releasing.html#release-numbering

The distinction between released and unreleased lies in a) process and
b) location of the bits. I think you're confusing process stages with
version numbering. I see no reasonable basis for imposing some
particular version numbering or release naming scheme on any project.


-- Brane


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

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

[Branko Čibej]

On 22.03.2015 00:02, Marvin Humphrey wrote:
 On Sat, Mar 21, 2015 at 2:30 AM, Dmitriy Setrakyan
 dsetrak...@apache.org wrote:

 On Fri, Mar 20, 2015 at 10:10 PM, Justin Mclean jus...@classsoftware.com
 wrote:
 Is this GPL software bundled or required?
 ./modules/core/src/main/resources/META-INF/licenses/gnu-gplv2ce-license.txt
 ./modules/geospatial/licenses/jts-lgpl-license.txt
 ./modules/hibernate/licenses/hibernate-lgpl-2.1-license.txt
 ./modules/schedule/licenses/cron4j-lgpl-2.1-license.txt

 These are optional runtime dependencies (GPL code is not present in the
 Apache Ignite source tree). The license text is provided on per-dependency
 basis to let the user know that if he/she chooses to include the
 dependency, then it will be under the specified license.
 I think whether that's OK is going to depend on how the Ignite code interfaces
 with any GPL code.  If it's going through a generalization layer a la JDBC
 which just happens to be implemented by GPL code, that might be OK.  If Ignite
 is implementing against a GPL-only interface, probably not OK even though the
 dependency is optional.  I think it would be best to pursue the matter
 further, either on the podling list, here, or on legal-discuss@apache.  Here's
 some prior discussion:

 http://apache.markmail.org/thread/i6uzkkyibxx7bniv

http://www.apache.org/legal/resolved.html says, on the topic of GPL and
similar:

Apache projects cannot distribute any such components. However, if
the component is only needed for optional features, a project can
provide the user with instructions on how to obtain and install the
non-included work. Optional means that the component is not required
for standard use of the product or for the product to achieve a
desirable level of quality.


Given the above, why are we still discussing this? Those are optional
components. Ignite works just fine without them.

When Subversion was incubating, 5 or so years ago, we went through the
same discussion regarding our dependency on Neon, even though it was
optional and Subversion works fine without any DAV plugin at all.
Subversion graduated while still having this (optional) dependency.

If you want to question Ignite's optional dependency on GPL code, you
should start by changing the published policy and making all TLPs throw
out such dependencies.

Not gonna happen, right?

-- Brane


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

Re: Podling Name Searches

[Branko Čibej]

On 25.01.2015 14:08, John D. Ament wrote:
 All,

 If a podling had its name and codebase donated from a company, which had
 already secured rights to the name,

The term secured rights is a bit misleading. Even if they have a
registered trademark, that's no guarantee that it doesn't infringe on
anything, especially in a different jurisdiction.

 what is required in the podling name search?

IMO, same as always. There's no reason for the ASF to implicitly trust
corporate lawyers. We should always look for names that are globally
unambiguous.

-- Brane


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

Re: my pTLP view

[Branko Čibej]

On 25.01.2015 19:51, Andrew Purtell wrote:
 That hardly ever happens (it's most likely when there are problems with
 ​ ​
 a podling's first few releases), which is why you get the impression
 ​ ​
 that the PPMC can make binding decisions.

 ​Close. The PPMC membership feels they have made a decision that matters
 with equal input.
 Certainly on PPMCs I've been on,
 ​there is awareness that everything is
 provisional
 ​. Still, a
  process takes place on PPMC mailing lists leading to a tallied outcome.
 The input that leads to this output is the consensus or voting of *a group
 of equal peers*.
 ​ This output is handed to the IPMC in aggregate. ​
 When casting votes on the PPMC lists there are no +1 (binding) or +1
 (non-binding) distinctions made. PPMC sends the outcome over to the IPMC
 feeling some level of ownership having just participated in a decision
 making process as equal
 ​s​
 . (Or at least so I think, in some perhaps quaint notion.) Of course in
 IPMC voting it is different, but the IPMC is where supervision happens, or
 doesn't, as some argue.

This is *exactly* the way things work in a TLP. Any committer can
propose a release. The PMC must (!) start a (public) vote. Anyone can
vote, with PMC votes being binding. /Any/ -1 vote, either from PMC
member or plain committer, should block the release and trigger a
discussion to find a solution; and in this discussion (which purpose is
to reach consensus on a solution), PMC members have no more voice than
any other community member.

If the PMC decides to ignore a -1 on a release vote, they'd better have
really good reasons for that, or I'd expect the Board to come down like
a ton of bricks on that PMC.

The situation is slightly different with new committer/PMC member
nominations and votes, which are private; you have a point there.

-- Brane

 On Sun, Jan 25, 2015 at 10:35 AM, Branko Čibej br...@apache.org wrote:

 On 25.01.2015 19:16, Andrew Purtell wrote:
 With a PPMC we invite newcomers to make votes we call binding on matters
 of
 their own project.
 As other people have said, PPMC members (that are not also IPMC members)
 do not have binding votes, neither for releases nor for inviting new
 committers/PPMC members. The binding bit lies with the IPMC, which can
 revoke any formal decision made by the PPMC.

 That hardly ever happens (it's most likely when there are problems with
 a podling's first few releases), which is why you get the impression
 that the PPMC can make binding decisions. In this respect, there's no
 practical difference between the current IPMC model and the proposed
 pTLP model.

 Of course, when it comes to /technical/ decisions, there's no such thing
 as a vote, so the term binding does not apply. Consensus, of one form
 or another, always rules: and the IPMC or mentors can't meddle in this
 case.

 -- Brane


 -
 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: my pTLP view

[Branko Čibej]

On 25.01.2015 19:16, Andrew Purtell wrote:
 With a PPMC we invite newcomers to make votes we call binding on matters of
 their own project.

As other people have said, PPMC members (that are not also IPMC members)
do not have binding votes, neither for releases nor for inviting new
committers/PPMC members. The binding bit lies with the IPMC, which can
revoke any formal decision made by the PPMC.

That hardly ever happens (it's most likely when there are problems with
a podling's first few releases), which is why you get the impression
that the PPMC can make binding decisions. In this respect, there's no
practical difference between the current IPMC model and the proposed
pTLP model.

Of course, when it comes to /technical/ decisions, there's no such thing
as a vote, so the term binding does not apply. Consensus, of one form
or another, always rules: and the IPMC or mentors can't meddle in this case.

-- Brane


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

Re: When is an ICLA needed?

[Branko Čibej]

On 20.01.2015 17:16, Ross Gardler (MS OPEN TECH) wrote:
 I agree with Bertrand. Note whoever commits the patch is doing so under their 
 ICLA.

Really? That can't be right: one can't become the author of a change
(and therefore can't license it to the ASF) merely by having committed
it. That's why we require an audit trail to the original author, right?

  In other words if someone feels it does not contain significant IP then they 
 can commit.

 Paperwork is a barrier to entry which is simply not necessary for trivial 
 contributions.

That's a different matter, and I agree.

-- Brane


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

Re: Open votes that have been open for more than 100 days ??

[Branko Čibej]

On 15.01.2015 17:57, Bertrand Delacretaz wrote:
 On Thu, Jan 15, 2015 at 5:20 PM, Branko Čibej br...@apache.org wrote:
 ...I'll go and kill that cron job then. Woot!...
 Can you also write a note at
 http://people.apache.org/~brane/incubator/votes.html to indicate that
 the service is discontinued?

 People might have bookmarked it.

Ack, done.

-- Brane


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

Re: Open votes that have been open for more than 100 days ??

[Branko Čibej]

On 15.01.2015 15:08, Marvin Humphrey wrote:
 On Thu, Jan 15, 2015 at 5:37 AM, jan i j...@apache.org wrote:

 I just looked at http://people.apache.org/~brane/incubator/votes.html, and
 I do understand that votes can be open for an extended period of time, but
 more than 100 days seems excessive:
 Back in June 2014, I suggested that this service be retired:

   http://s.apache.org/22q

 No one objected, and I removed the links to it.  I don't think we
 should bring it back now; as Brane notes, keeping it up-to-date
 requires significant ongoing fiddling.

 Thanks once again to those who helped maintain it.  It helped to prod
 changes which brought the Incubator out of perpetual crisis.

You're welcome. I'll go and kill that cron job then. Woot!

-- Brane


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

Re: Open votes that have been open for more than 100 days ??

[Branko Čibej]

On 15.01.2015 15:06, jan i wrote:
 On 15 January 2015 at 14:58, Branko Čibej br...@apache.org wrote:

 On 15.01.2015 14:45, Dave wrote:
 This vote: RC4 as Apache Usergrid 1.0 (incubating) 2014–09–03 2014–09–02
 135 days was cancelled in an email message titled [VOTE][CANCELLED]
 Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION
 The problem here is that the vote tally script does not expect people to
 fiddle with the subject line other than to add a [RESULT] or [CANCEL] or
 [CANCELLED] tag. In the past, I've found quite a few result or
 cancellation messages that also modify the rest of the subject line, or
 even start a completely new thread. Every now and then I go through the
 script's database and fix up results, but ... I'd really have expected
 people to feel less need to fiddle with subject lines. :)

 (At one point I tried following in-reply-to headers ... what a mess,
 mail clients these days really have trouble following 20-year-old RFCs.)

 Does the program have any other method to cancel votes than making an email
 ?
 (would be kind of nice of IPMC could mark votes like the one from Usergrid,
 without extra emails)

Yeah, it would be nice; and the answer is, not yet. It's just a cron job
that generates static HTML, running off my account on minotaur.

At one time I had this utopian plan for changing the whole thing into a
nice webapp, but ... heh. Went the way of all other Utopias.


 And of course, some votes never get a proper resolution mail sent out.

 Those are the ones we need to catch.

Yup. That was the point of trying to automate the whole thing.

-- Brane


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

Re: Open votes that have been open for more than 100 days ??

[Branko Čibej]

On 15.01.2015 14:45, Dave wrote:
 This vote: RC4 as Apache Usergrid 1.0 (incubating) 2014–09–03 2014–09–02
 135 days was cancelled in an email message titled [VOTE][CANCELLED]
 Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION

The problem here is that the vote tally script does not expect people to
fiddle with the subject line other than to add a [RESULT] or [CANCEL] or
[CANCELLED] tag. In the past, I've found quite a few result or
cancellation messages that also modify the rest of the subject line, or
even start a completely new thread. Every now and then I go through the
script's database and fix up results, but ... I'd really have expected
people to feel less need to fiddle with subject lines. :)

(At one point I tried following in-reply-to headers ... what a mess,
mail clients these days really have trouble following 20-year-old RFCs.)

And of course, some votes never get a proper resolution mail sent out.

-- Brane

 On Thu, Jan 15, 2015 at 8:37 AM, jan i j...@apache.org wrote:

 Hi

 I just looked at http://people.apache.org/~brane/incubator/votes.html, and
 I do understand that votes can be open for an extended period of time, but
 more than 100 days seems excessive:

 Apache Drill 0.6.0-incubating release 2014–10–20 2014–10–05 102 days
 Accept
 Ignite into the Apache Incubator 2014–10–01 2014–10–01 106 days  Release
 RC4 as Apache Usergrid 1.0 (incubating) 2014–09–03 2014–09–02 135 days
 Release
 Apache Flink 0.6-incubating 2014–08–22 2014–08–18 150 days  Release BatchEE
 0-2-incubating 2014–08–10 2014–08–10 158 days  Release Apache DeviceMap
 BrowserMap version 1.4.1 2014–07–30 2014–07–25 174 days  Release of Apache
 MRQL 0.9.2 incubating (RC2)) 2014–06–26 2014–06–25 204 days  Graduate
 Apache Celix as Top Level Project 2014–06–23 2014–06–19 210 days  Apache
 Slider 0.30-incubating RC0 2014–06–02 2014–06–02 227 days
 Could I politely ask the different projects to have a look if these votes
 still are active, or alternatively close/cancel them.


 thanks in advance
 rgds
 jan i.



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

Re: What is The Apache Way?

[Branko Čibej]

On 08.01.2015 05:30, Marvin Humphrey wrote:
 On Wed, Jan 7, 2015 at 12:54 PM, Alan D. Cabrera l...@toolazydogs.com wrote:

 Some podlings are graduating w/ no clear understanding of the Apache Way.
 What is The Apache Way?  No one can say.

 There is no bounded set of expectations that an Apache project must fulfill.

 Where do Apache's official policies begin and end?  Which best practices
 must be mastered?  What will be enforced, what will be ignored?

 Every last podling graduates without a clear understanding of The Apache
 Way, because it is impossible to attain a clear understanding of The Apache
 Way.


Dunno, I think the basics are pretty clear.

  * Contributors are individual volunteers (never representatives of
employers).
  * Status is gained through merit (e.g., not through connections or
tit-for-tat).
  * Decisions should be reached by consensus.
  * All project members are equal (e.g., PMC does not dictate to other
committers)
  * Community is more important than code.

Everything else (including requirements for releases) are minor
technicalities and/or legal constraints.


I find it horrifying that any ASF and especially IPMC member couldn't
list these five basic points standing on their heads in a cold shower at
3 a.m.

-- Brane


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

Re: proposal: mentor re-boot

[Branko Čibej]

On 07.01.2015 22:45, Henry Saputra wrote:
 If a mentor asked to stay as PMC after graduation just for the sake of
 continue mentoring,

then I would argue that the podling was not ready for graduation. A
graduated TLP inviting the former mentor to the PMC is a different
matter, but then the IPMC has neither mandate nor power to remove that
person from the PMC.

-- Brane

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

Re: proposal: mentor re-boot

[Branko Čibej]

On 07.01.2015 18:42, Alan D. Cabrera wrote:
 I’ve written up a more comprehensive proposal that would not only hold 
 mentors accountable but also give them a fair bit of autonomous authority 
 during releases.

 https://wiki.apache.org/incubator/MentorRebootProposal 
 https://wiki.apache.org/incubator/MentorRebootProposal

 What we would gain is transparency and simplicity.  There would be no false 
 expectations.  Podlings would know where they stand.  Work would be equitably 
 distributed.

 No more layers.  No more additional roles and confusing/diluted 
 responsibilities.  No more shuffling.

What you're proposing, then, is that we institute mentor licenses with
requirements over and above those for ASF membership. In effect, you'd
create an additional level of earned merit for mentors ... which is
probably a good thing.

What I don't understand is this: where's the motivation for anyone to
submit to this additional burden? There's a lot of stick in your
proposal, but a woeful lack of carrot ... so, most likely not going to
work for a bunch of volunteers.

-- Brane

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

Re: Git write access for podlings

[Branko Čibej]

On 02.01.2015 11:36, Stian Soiland-Reyes wrote:
 Apache Commons has already given write access to *all* ASF committers

So did Subversion, quite a while ago.

If you get rogue commits from someone, the solution is not extra tooling
but community management. Even more so in the case of the Incubator,
where access is restricted to IPMC members and podling committers — all
of whom should be well aware that you can't just go messing in some code
without checking with the project community first.

Understanding the concept of community over code and how to
collaborate is a requirement for new committers and triply so for IPMC
members.

-- Brane


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

Re: Incubator report sign-off

[Branko Čibej]

On 22.12.2014 17:42, Roman Shaposhnik wrote:
 Thus, to me, the choice is really about #1 and #3. So perhaps, the
 path forward is to try #3 first and then, if things don't improve, go
 all the way to #1. Please let me know what do you think.

+1

 Sure, we might reduce the number of projects coming into the foundation
 but (IMHO) that is not a problem. Our goal as a foundation is not to be
 large, it is to be high quality.
 But it is to be high quality on the level of understanding of the 'Apache Way'
 which has very little to do with the quality of code, documentation or any
 other piece of technology.

That's my take as well. Meritocracy; community structure; when to vote
and especially when *not* to vote; requirements for releases, etc. and
the reasons for all of the above are the things that a mentor should be
expected to keep an eye on. Especially at the beginning of incubation,
because bad habits are harder to break later on.

-- Brane


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

Re: Votes for git repos - commit id vs tag

[Branko Čibej]

On 20.12.2014 07:16, Niclas Hedhman wrote:
 Tags are at best a convenience, and nothing else. But so are commit id,
 since in the long-term, GIT may not prevail and the commit id is in effect
 an internal artifact of Git itself, not the concept of version control
 systems. Compare how commit numbers from Subversion are imported to Git
 repositories, or not... But tags are imported, if the ttb structure in
 subversion is used.

Any release is cut from a current canonical repository, which is always
hosted on ASF infrastructure. The point is that current releases should
be identifiable in the current repository, because anyone who votes on a
release /should/ verify that the tarball matches some state in the repo;
otherwise they don't know what they're signing, and the release isn't
repeatable; that would sort of negate the whole point of version control.

In the case of Git, the commit-id is the most stable global identifier
for a particular state of the repository. (I say most stable because,
in general, Git history is mutable ... sigh).

If at some future date the repository is imported in some shiny new
version control system, that new system is bound to have some kind of
global state identifier, mutable or not; and commit-ids may or may not
be accurately represented by it; but that's completely irrelevant for
current releases. It's marginally relevant for reproducing past
releases, but that can be solved by archiving the whole old repository.

-- Brane

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

Re: Incubator report sign-off

[Branko Čibej]

On 19 December 2014 at 18:10, Rich Bowen rbo...@rcbowen.com wrote:
 I certainly don't expect that every mentor has their full attention on a
 podling every month, but I do expect that a podling that cares about its
 incubation will seek out that mentor sign-off, and that the mentors who have
 committed to help a podling into the family will have a few moments every
 few months to look in and approve a report.


I have to disagree. If someone volunteers to be a mentor, they should
commit to checking the podling's progress on a daily basis, not just
once every few months. There are some people on the IPMC who are
mentors to a plethora of podlings; I can never understand how they
expect to do their job, and the fact that there are so many absent
mentors tends to suggest that they don't.

Certainly, we're all volunteers here. But being a volunteer does not
imply that one doesn't have to take their task seriously. If someone
runs out of time, the least I'd expect would be notifying the IPMC and
the podling about that and arranging for a new mentor. Otherwise, I
expect not only monthly (or quarterly) sign-offs, but regular
oversight and moderately active involvement in the community. Because
after all, how are people supposed to learn how things are done
hereabouts, if not from active mentors?

In that note ... i'd propose that, if a mentor does not sign off on a
report, said mentor should be reminded once; if nothing changes, they
should be removed and replaced by someone else.

-- Brane

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

Re: Mail command to allow marvin emails

[Branko Čibej]

On 26.11.2014 10:45, Stian Soiland-Reyes wrote:
 I can appreciate that these kind of shortcuts can make it efficient for an
 experienced moderator, but for incubating projects who are transitioning
 from infrastructure like Github, Google Groups and yes, even Sourceforge,
 getting used to the apache.org infrastructure is a bit of a challenge, even
 for dinosaurs like myself who used this kind of technology 15 years ago.

 /rant ;)

Let me continue in the same vein by asking: do you really think we want
committers who can't figure out technology unless it's packed in a
really simple GUI with no more than a single line of text anwhere? :)

(If you're a dinosaur, would this make me a sauropsid?)

-- Brane

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

Re: [VOTE] Graduation of Apache Falcon from the Incubator

[Branko Čibej]

On 05.11.2014 16:05, Srikanth Sundarrajan wrote:
 Hi Jan,
 Venkatesh Seetharam is extremely active on the project, but couldn't vote 
 on this thread,

Why not? Are you guys by any chance treating project committers and PPMC
members differently?

-- Brane

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

Re: [VOTE] Graduation of Apache Falcon from the Incubator

[Branko Čibej]

On 05.11.2014 16:32, Srikanth Sundarrajan wrote:
 Hi Brane,
No, He just didn't get to it before the vote was closed. As I had stated 
 in my earlier response, he has already expressed his views on graduation in 
 the earlier discuss thread that preceded the vote. Adding it here for 
 reference.

Ah. Thanks for clarifying.


 http://mail-archives.apache.org/mod_mbox/incubator-falcon-dev/201410.mbox/%3CCAFfn_Rru5Q%3Dps3EMEneUsqUyuy7p5quyp35YHdkbE4o-p%2BpmJw%40mail.gmail.com%3E

 Regards
 Srikanth Sundarrajan

 Date: Wed, 5 Nov 2014 16:27:53 +0100
 From: br...@apache.org
 To: general@incubator.apache.org
 Subject: Re: [VOTE] Graduation of Apache Falcon from the Incubator

 On 05.11.2014 16:05, Srikanth Sundarrajan wrote:
 Hi Jan,
 Venkatesh Seetharam is extremely active on the project, but couldn't 
 vote on this thread,
 Why not? Are you guys by any chance treating project committers and PPMC
 members differently?

 -- Brane

 -
 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] [PROPOSAL] HTrace for Apache Incubator

[Branko Čibej]

On 03.11.2014 16:49, Stack wrote:
 On Sun, Nov 2, 2014 at 6:19 PM, Naresh Agarwal naresh.agar...@inmobi.com
 wrote:

 Just curious if HTrace is aimed only for Hadoop infrastructure/Hadoop based
 applications or it can be used in any Java based systems?


 HTrace's provenance is Hadoop but the only hadoop 'taint' in HTrace is the
 leading 'H' in its name; it should be fit for any java distributed systems.

 Lets make this more plain in the proposal.

Would it hurt to remove the H from the project name, then?

(I won't propose replacing it with D, that would be really confusing.)

-- Brane

P.S.: Ooh ... Distributed Tracing - Distress, which happens to be
what an admin feels when her distributed app goes wonkers ...

-- Brane

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

Re: [DISCUSS] [PROPOSAL] HTrace for Apache Incubator

[Branko Čibej]

On 03.11.2014 19:12, Stack wrote:
 On Mon, Nov 3, 2014 at 8:01 AM, Branko Čibej br...@apache.org wrote:

 On 03.11.2014 16:49, Stack wrote:
 On Sun, Nov 2, 2014 at 6:19 PM, Naresh Agarwal 
 naresh.agar...@inmobi.com
 wrote:

 Just curious if HTrace is aimed only for Hadoop infrastructure/Hadoop
 based
 applications or it can be used in any Java based systems?


 HTrace's provenance is Hadoop but the only hadoop 'taint' in HTrace is
 the
 leading 'H' in its name; it should be fit for any java distributed
 systems.
 Lets make this more plain in the proposal.
 Would it hurt to remove the H from the project name, then?

 (I won't propose replacing it with D, that would be really confusing.)

 -- Brane

 P.S.: Ooh ... Distributed Tracing - Distress, which happens to be
 what an admin feels when her distributed app goes wonkers ...

 HTrace is 'fairly' generic and the github project is what comes up when you
 search. That said, I think your suggestion pretty great, funny. Its
 probably a bad name for a software project though? (Distrace?)

If Subversion and Git are OK, then Distress fits right in, wouldn't you
say? :)

-- Brane


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

Re: Convenience Binary Policy

[Branko Čibej]

On 21.10.2014 15:55, Harbs wrote:
 The one thing I see missing from the proposed text is dependencies and 
 installers.

 Particularly this section:
 ### Compiled packages ### {#compiled-packages}

 The Apache Software Foundation produces open source software. All releases
 are in the form of the source materials needed to make changes to the
 software being released.

 As a convenience to users that might not have the appropriate tools to build a
 compiled version of the source, binary/bytecode packages MAY be distributed
 alongside official Apache releases.  In all such cases, the
 binary/bytecode package MUST have the same version number as the source
 release and MUST only add binary/bytecode files that are the result of
 compiling that version of the source code release.
 ---
 How do binary dependencies fit in?

Binary dependencies are, by definition, not released by the ASF; because
we release source code. Also, software that has dependencies that are
only available in binary form is not open-source, in my book.

-- Brane

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

Re: Convenience Binary Policy

[Branko Čibej]

On 21.10.2014 06:34, Alex Harui wrote:
 What is the piece I’m missing that says we have to vote to update the
 binary package?

Apparently the Flex community believes that convenience binaries need
votes. They don't, but aside from that, if you guys are already voting
on binary packages, it makes perfect sense to vote for your fixed
version, if only to keep people happy.


-- Brane

P.S.: Why anyone would think voting on binaries makes any kind of sense
around here is, of course, a different question. I can't even begin to
count the number of times it's been pointed out that binaries are not
Apache releases.


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

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Branko Čibej]

On 13.10.2014 16:14, Julian Hyde wrote:
 For many projects, especially library projects, the convenient binaries 
 that matter most these days are the jars (source, binary, and javadoc) that 
 are deployed to the maven repo. Calcite releases in fact do not currently 
 include a binary tar ball, only a source tar ball and maven jars. 

 Are these jars subjected to due diligence during the release vote? It seems 
 to me that each of those jars is a de facto binary release.

If it contains sources, it's not a binary release. Binary JARs are
definitely a binary release. I haven't a clue what Javadocs are, but
since they're derived from the sources, I'd prefer to put them in the
binary category for simplicity.

But that's beside the point. Convenience binaries are anything that
was created from the properly voted-on and released source that did not
go through the same formal release proces as the source release. If the
PMC did not vote on the binary JARs, they are not an Apache Release and
therefore none of our guarantees (or liabilities) can apply to them.

-- Brane


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

Re: svn commit: r1631099 - /incubator/public/trunk/content/projects/ignite.xml

[Branko Čibej]

On 12.10.2014 14:24, sebb wrote:
 On 11 October 2014 20:15,  c...@apache.org wrote:
 Author: cos
 Date: Sat Oct 11 19:15:17 2014
 New Revision: 1631099

 URL: http://svn.apache.org/r1631099
 Log:
 Updating Ignite website with initial INFRA task dates

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

 Modified: incubator/public/trunk/content/projects/ignite.xml
 URL: 
 http://svn.apache.org/viewvc/incubator/public/trunk/content/projects/ignite.xml?rev=1631099r1=1631098r2=1631099view=diff
 ==
 --- incubator/public/trunk/content/projects/ignite.xml [utf-8] (original)
 +++ incubator/public/trunk/content/projects/ignite.xml [utf-8] Sat Oct 11 
 19:15:17 2014
 @@ -91,12 +91,6 @@
td./td
td./td
  /tr
 -mentor username=braneBranko Čibej/mentor
 -mentor username=cosKonstantin Boudnik/mentor
 -mentor username=hsaputraHenry Saputra/mentor
 -mentor username=rvsRoman Shaposhnik/mentor
 -mentor username=stackMichael Stack/mentor
 -
 Why were the mentor names dropped?


They weren't dropped; these were duplicates in the wrong place. All five
are still listed as mentors on this page.

-- Brane

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

Re: Committer Voting and Vetos

[Branko Čibej]

On 01.10.2014 05:41, Greg Stein wrote:
 On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning ted.dunn...@gmail.com wrote:

 On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein gst...@gmail.com wrote:

 To the concrete question, the Subversion project never calls a strict
 [VOTE] for new committers or PMC members. We discuss first, and that sets
 the direction. People throw out +1 messages, but that is sure, make it
 so
 rather than a true vote. Whenever somebody says wait a minute, then we
 do. We don't have formal rules around this stuff, since a general goal of
 consensus is so ingrained into the community.

 The nice thing about the vote is that there is a [RESULT] message to link
 to.  What does the Subversion project link to in the account request?

 We don't provide a link. There is no reason for Infrastructure to
 second-guess account requests from Officers or ASF Members, so that link is
 optional. *Should* a question ever arise, then it is easy enough to provide
 background information.

Yup. I see the link field there as being mainly for the benefit of the
Incubator and podlings.

-- Brane


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

Re: [VOTE] Accept Ignite into the Apache Incubator

[Branko Čibej]

On 28.09.2014 02:58, Konstantin Boudnik wrote:
 I would like to call a vote for accepting Apache Ignite for Apache 
 Incubator.
 The full proposal is available below. We ask the IPMC to sponsor it, with cos
 as Champion, and stack, rvs, cos, hsaputra and brane volunteering to be 
 Mentors.

 Please cast your vote:

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

+1 (binding)

-- Brane

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

Re: Code Donations and Committer Righs

[Branko Čibej]

On 26.09.2014 20:03, jan i wrote:
 On 26 September 2014 19:23, Roman Shaposhnik ro...@shaposhnik.org wrote:

 Just like Ross, the following constitutes my personal opinion
 (that has been formed over the years of maintaining complex
 code bases written before my time):

 On Fri, Sep 26, 2014 at 10:04 AM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 OK. I will give you my personal opinion since you are seeking to drive
 consensus...
 I would say that if the code is of sufficient quality and relevance for
 the project to want
 to accept it then contributors should be given commit rights.
 I would even go further than this: to me a brand new code donation
 without anybody donating that code willing to sign up to maintain
 it (at least for as long as it takes for others to ramp up) spells orphaned
 code.

 IOW, for sizable brand new contribution the commit rights of somebody
 familiar with the code shouldn't be a question, but more of a prerequisite
 to actually accepting that contribution in the first place.

 my personal opion is a big +1 to not accepting bigger contributions if the
 programmers (or at least part of them) comes along. Getting new code
 without people that understand it deeply, is really asking for trouble.

I tend to agree. However, there's more than one aspect to the issue:
your typical ASF committer does not only contribute and maintain code;
she also participates in the process of managing the project and
community. The more so on projects that do not make a difference between
committer and PMC member.

It may not always be the case that someone who makes a software grant is
also aware of how the project and community work. On the other hand, one
would expect that the existing community members are able to help such
new contributors over the initial hurdles of adapting to the (drumroll)
Apache Way.

So ... it's essentially a toss-up, but personally I'd prefer
inclusiveness over control-freakness.

-- Brane

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

Re: [PROPOSAL] Silk as new Incubator project

[Branko Čibej]

On 27.09.2014 05:38, Konstantin Boudnik wrote:
 Hi David.

 I believe it will be needing a usual place to publish releases

Release tarballs go here before the release vote starts:

https://dist.apache.org/repos/dist/dev/incubator/ignite

After the vote passes, they should be moved here:

https://dist.apache.org/repos/dist/release/incubator/ignite

Feel free to create the ignite directories as necessary.


Note that .../release/... is distributed to mirrors; over at Subversion,
we wait 24 hours between moving release bits to .../release/... and
announcing the release, to make sure that all mirrors have caught up.
Only the latest reelase should be there, any older versions must be
deleted. They should have been automagically moved to

http://archive.apache.org/dist/incubator/ignite

fairly soon after they appear on dist.apache.org; if they don't, nudge
Infra.

-- Brane


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

Re: [PROPOSAL] Grill as new Incubator project

[Branko Čibej]

On 23.09.2014 14:37, Jean-Baptiste Onofré wrote:
 I like Lens indeed.

Sooo ... I suppose the PMC chair will be called the Grey Lensman then? :)

-- Brane


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

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating)

[Branko Čibej]

On 02.09.2014 15:51, Dave wrote:
 On Tue, Sep 2, 2014 at 9:43 AM, John D. Ament john.d.am...@gmail.com
 wrote:

 So... do you have a 1.0 artifact staged somewhere? I get that it's a
 rebuild of RC4, but I don't see that release referenced anywhere on your
 site.

 The release files are here: http://people.apache.org/~snoopdave/usergrid/

Release bits have to be in SVN, not in some random location on some
random server. In your case:

https://dist.apache.org/repos/dist/dev/incubator/usergrid

before it's released and in

https://dist.apache.org/repos/dist/release/incubator/usergrid

after the release vote has passed and usually 24 hours before the
release is announced. Neither of these directories exist.

-- Brane


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

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION

[Branko Čibej]

On 03.09.2014 05:03, Jake Farrell wrote:
 Hi John
 I requested that Dave add the RC tag to better keep track of multiple
 release candidates and make it easier for testing and not mixing any
 previous version up accidentally. This is very common and currently done in
 many TLP's including Thrift, Mesos, and Cassandra to name a few.

Agreed. And it is (or should be) normal process to start a new vote for
every new set of release bits. Even if 1.0.0 is just a repackaging of
1.0.0-rc4, there may be bugs in the packaging process itself (such as
we've seen in this thread, when files that were not intended to be
released were bundled in the release artefacts), so the PPMC should test
and vote again.

The vote should always refer to a particular release package (taken from
dist/dev), not to some tag in the repository.

-- Brane


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

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION

[Branko Čibej]

On 02.09.2014 23:06, Dave wrote:
 Rats. That directory should not have been included in the release. It
 is created as part of the build process and the contents are fetched
 by Bower (similar to how Maven pulls in jars). Thanks for your
 attention to detail. I will have a new set of release files shortly
 and will restart the vote.

Please don't forget to cancel this vote by replying to the vote thread
and adding a [CANCEL] or [CANCELLED] tag before the [VOTE] tag in the
subject. Otherwise the vote tracker will not know that the vote has been
closed and will keep tracking it forever.

-- Brane

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

Re: Websites, WebApps, and Release Policy

[Branko Čibej]

On 26.08.2014 00:24, Justin Mclean wrote:
 Hi,

 This strikes me very similar to providing access to daily SNAPSHOT binary
 artifacts. I would argue that labeling it appropriately is all you
 need.
 Except that is this case the intended audience of the application is users.

Bloodhound has maintained two VMs that host publicly available
development snapshots since it was a podling, and still does today, more
than a year after it graduated. The situation is exactly the same; the
snapshots are clearly marked as development work in progress, the
sources of the running instances are freely available from SVN to anyone
with a web browser. There has never been any confusion as to whether
these snapshots are an ASF Release or not.

-- Brane


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

Re: Package naming for several languages

[Branko Čibej]

On 30.01.2014 21:16, Kowalski, Francois-Xavier wrote:
 My $0.1: stick with the language rather than with the platform:

Because it's well-known that API implementations are never
platform-specific. :)


 *-js/
 *-objc/
 *-cs/


 —FiX

 -Original Message-
 From: Lewis John Mcgibbney lewis.mcgibb...@gmail.com
 Reply-To: general@incubator.apache.org general@incubator.apache.org
 Date: Thursday 30 January 2014 19:46
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Package naming for several languages

 Hi Folks,
 Currently we are working on getting correct package naming implemented
 within Apache Usergrid (incubating).
 The Usergrid codebase contains SDK's in several languages... no biggie,
 however what I am unsure about is how package naming should be implemented
 in dotnet [0], html5-javascript[1], ios[2], etc packages?
 Any direction would be very handy.
 Thanks in advance
 Lewis

 [0] https://github.com/usergrid/usergrid/tree/master/sdks/dotnet
 [1] https://github.com/usergrid/usergrid/tree/master/sdks/html5-javascript
 [2] https://github.com/usergrid/usergrid/tree/master/sdks/ios

 -- 
 *Lewis*

 -
 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

Please remember to post [CANCEL] notes for cancelled votes

[Branko Čibej]

The voting status script relies on them to update its tables. Currently
there are a number of votes flagged as out of date:

http://people.apache.org/~brane/incubator/votes.html

however, many (if not most) of them were actually cancelled, in some
cases replaced by another (successful) voting thread.

I originally wrote that script because it was often quite hard to figure
from the mail archives which votes were current. If vote proposers don't
make the effort to manage the voting threads, the script ends up being
useless.

Thanks,

-- Brane

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

Re: [PROPOSAL] - Java OffHeap Memory Pool

[Branko Čibej]

Is code for this available for review anywhere?

-- Brane

On 16.04.2013 19:46, serkan özal wrote:
 Project Name: Jillegal


 1. Abstract:
 GC is one of the time taken operations in Java. GC run anytime, marks, swaps 
 and compacts objects at memory. If there are so many live objects, managing 
 them by GC leads to overhead. If objects can be allocated outside of GC, 
 there will be no overhead for the application. The session will go through 
 the new method of creating and using object off-heap with no additional 
 serialization/deserialization or any other overheads. 


 2. Proposal:
 For off-heap memory, I propose a solution that objects are allocated and 
 initialized at off-heap instead of heap. Not only object attributes are 
 allocated at off-heap, but also object header and metadata are allocated at 
 off-heap. So while a reference to this object at off-heap is being 
 interpreted, JVM knows which class this object references to. You can get 
 your off-heap object from an object pool instead of with new operator. This 
 object pool allocates a fixed size memory region from off-heap and create 
 empty objects with given class on there. These empty objects can be created 
 as lazy or eager. Another advantage off this technique is that objects in 
 pool are layout in memory as sequential. While accessing an object, its 
 neighbour objects are also fetched to CPU cache, so CPU cache hit rate for 
 sequential object accesses are increased. On the other hand, freeing unused 
 objects is responsibility of developer by calling free method of object 
 pool which means there is no dead object detection mechanism like GC. 
 Therefore, getting all objects from off-heap for whole application is 
 dangerous and not recommended. Because, this will cause memory leaks. In 
 addition, this technique can be combined with Java Instrumentation API. 
 With @FromOffHeap annotation, developer can sign classes these must be 
 allocated from off-heap instead of heap. With Java Instrumentation API, all 
 new operators for signed classes with @FromOffHeap annotation can ben 
 transformed to code that allocates objects of signed class from off-heap via 
 object pool. So developer doesn't change all new keywords for getting from 
 object pool in code. Instread of this, just sign class with @FromOffHeap 
 annotation and all new keywords transformed for getting from object pool at 
 class load time. This technique was used at a real time CDR processing system 
 for Turk Telekom. There were billions of objects were used. Managing these 
 objects by GC caused to performance overhead. For some most used classes, we 
 allocated these objects from off-heap instead of new keyword. After some 
 processings on them (takes 4-5 hours), we release these allocated memory 
 regions to operating system by freeing them. Allocating objects from off-heap 
 pool helps us to gain significant execution time performance.


 3. Rationale:
 In general, off-heap pool implementations are implemented by 
 serialization/deserialization to allocated off-heap memory region via 
 ByteBuffer class. But this technique leads to extra execution overhead. 
 Because while reading from an object, the target object must be created by 
 deserializing all primitive fields eagerly or only required fields on demand 
 and while writing to an object, the attribute has been set by application, 
 must be deserialized to allocated off-heap memory region. In addition, 
 objects itself is created at heap, so GC knows and tracks it. With my 
 solution, all of these overheads are overcomed.


 4. Initial Goals:
  * Allocating objects from off-heap and using them as normal on-heap 
 Java object. * Allocating arrays for object types from off-heap and 
 using them as normal on-heap Java object arrays. * Allocating arrays 
 for primitive types from off-heap and using them as normal on-heap Java 
 primitive type arrays. * Allocating strings from off-heap and using 
 them as normal on-heap strings. * Implementing auto expandable 
 off-heap pool that expands when its delegated off-heap pool implementation is 
 full. * All features must be supported for 32 bit and 64 bit JVM. 
 * All features must be supported for Sun HotSpot JVM, Oracle JRockit, IBM 
 J9.

 5. Currently Implemented Features:

  * Allocating objects from off-heap and using them as normal on-heap 
 Java object * Allocating arrays for object types from off-heap and 
 using them as normal on-heap Java object array * Allocating arrays 
 for primitive types from off-heap and using them as normal on-heap Java 
 primitive type arrays * Implementing auto expandable off-heap pool 
 that expands when its delegated off-heap pool implementation is full. 
 * All features are supported for 32 bit and 64 bit JVM. * All 
 features are supported for Sun HotSpot JVM, Oracle JRockit (IBM J9 support 
 will be added).


 6. Roadmap
  

Re: [VOTE] Apache Onami to become an ASF TLD

[Branko Čibej]

On 18.03.2013 11:25, Bertrand Delacretaz wrote:
 Hi,

 On Mon, Mar 18, 2013 at 8:01 AM, Christian Grobmeier
 grobme...@gmail.com wrote:
 ...in the previous discussions were no objections against the graduation
 of Apache Onami...
 Was there a community vote indicating a desire to graduate?

This is the community vote. It's a bit confusing that it's also cc:'d to
general@.

-- Brane


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

Re: [VOTE] Apache Onami to become an ASF TLD

[Branko Čibej]

On 18.03.2013 11:35, Mohammad Nour El-Din wrote:
 Hi

Last time I checked the rules it state that, for such votes, the IPMC
 should be *notified* through general@

This VOTE is not a requirement but is recommended. It is unlikely
that IPMC members will vote to approve graduation unless the Mentors
and community positively express their readiness for graduation. It
is wise to copy the incubator general list when the vote is proposed.


I see no requirement to notify. And I still maintain it's confusing, as
evidenced by this very case.

It would make more sense if general@ were notified after the fact of the
vote result, e.g., as an addendum to the graduation vote proposal.
There's absolutely no call for the IPMC to poke our fingers into what
are obviously optional, internal podling procedures. That's almost as
bad as doing code reviews for them.

-- Brane

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

Re: [RESULT][VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Branko Čibej]

Just tagging the [RESULT] onto the subject so that the vote status gets
updated.

On 24.02.2013 04:36, Devaraj Das wrote:
 Hi folks,
 With 10 binding +1 votes, this vote has passed.  Thanks to everyone who
 voted.
 Devaraj.
  +1 (binding)

 On Feb 15, 2013, at 11:22 AM, Devaraj Das 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 

[RESULT][VOTE] Accept Tez into Incubator

[Branko Čibej]

On 25.02.2013 05:44, Arun C Murthy wrote:
 Thanks to all who voted. Obviously, I'm +1 (binding) on the proposal.

 With 14 +1s (10 binding) the vote passes.

 I'll start the work to get the podling started.

 thanks,
 Arun

 On Feb 19, 2013, at 8:26 PM, Arun C Murthy 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 

[RESULT][VOTE] Accept Provisionr into the Apache Incubator

[Branko Čibej]

On 07.03.2013 08:54, Andrei Savu wrote:
 Thanks to all who voted! With 18 +1s (10 binding) the vote passes.

 I'll start the work to get the podling started.

 Thanks,
 Andrei

 On Mon, Mar 4, 2013 at 9:31 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 +1 non-binding

 Good luck


 On Sat, Mar 2, 2013 at 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 

Re: [VOTE] Graduate Apache Bloodhound from Incubator

[Branko Čibej]

On 11.03.2013 05:04, Kalle Korhonen wrote:
 Was the potential trademark conflict discussed somewhere? See
 http://mail-archives.apache.org/mod_mbox/incubator-general/201212.mbox/%3c50ca29ad.6000...@apache.org%3E-
 if so, just linking to the discussion is fine.

It was discussed on trademarks@; the thread starts with
201302.mbox/51259463.4030...@wandisco.com

That thread overlaps another in bloodhound-private@, which starts with
201302.mbox/5125124d.8060...@wandisco.com

Both messages are from Gary. Note that I'm not going to post links to
the private archives, I'm sure these breadcrumbs and
mail-search.apache.org will help you find the discussions.

-- Brane


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

Re: [VOTE] Graduate Apache Bloodhound from Incubator

[Branko Čibej]

 [X] +1 Graduate Apache Bloodhound podling from Apache Incubator

-- Brane

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

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 03.02.2013 21:26, Christian Grobmeier wrote:
 Just to be clear, in the case of Onami Logging, reviewers are  asked to
 find the right package amongst 8 different source packages in 8
 different directories.
 What do you mean with right? They all are right, because they
 contain different sources and we want to release them all.

In the end I realized that only the -parent.zip contained all the
sources and was comparable to the contents of the release tag in SVN.
This should, IMO, be better communicated in the vote announcement.

The fact that the NOTICE files in the other source .jars are not
identical to the one in the source .zip, or in the release tag, is
(putting it mildly) confusing.

 Impossible? I have to disagree. One can:

 wget -r -l 1 -np -nH -nd -nv -e robots=off --wait 10
 --no-check-certificate
 https://repository.apache.org/content/repositories/orgapacheonami-150/

 and easily gets all files.

Yes. I'm not interested in checking a lot of binaries. They're not part
of the release, right?

-- Brane


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

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 04.02.2013 01:05, Mohammad Nour El-Din wrote:
 Hi Branko...


 On Sun, Feb 3, 2013 at 10:31 PM, Branko Čibej br...@apache.org wrote:

 On 03.02.2013 21:26, Christian Grobmeier wrote:
 Just to be clear, in the case of Onami Logging, reviewers are  asked to
 find the right package amongst 8 different source packages in 8
 different directories.
 What do you mean with right? They all are right, because they
 contain different sources and we want to release them all.
 In the end I realized that only the -parent.zip contained all the
 sources and was comparable to the contents of the release tag in SVN.
 This should, IMO, be better communicated in the vote announcement.

 I agree this might be a helpful detail but not a mandatory or necessary one
 as it can be deduced from the structure of the project

Only if you happen to be familiar with Maven.

-- Brane


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

Re: Incubator voting status page

[Branko Čibej]

On 01.02.2013 20:48, sebb wrote:
 On 1 February 2013 16:29, Branko Čibej br...@apache.org wrote:
 On 01.02.2013 17:01, sebb wrote:
 On 1 February 2013 10:29, Branko Čibej br...@apache.org wrote:
 On 31.01.2013 17:18, Branko Čibej wrote:
 On 31.01.2013 16:51, Daniel Shahaf wrote:
 Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
 I guess it's best if I ping infra and ask about getting this done (or
 probably file an INFRA ticket). Infra are also in the best position to
 know if we can have the page regenerated more often, e.g., once an hour.
 The first issue I see is that your script assumes it has local access to
 the public-arch tree, so it can only run on minotaur (or on the
 mail-archives.a.o box).
 Ah, that's a good enough point for doing the dynamic-include thing.
 Initially I thought I'd be downloading the mboxes from mail-archives,
 but ... local access is soo much faster and easier.

 I'll make it work as Christian suggested then.
 And it's done. An embedded status page is created on minotaur and
 dynamically embedded into the new vote status page. There are only two
 issues:

   * It'll take a while for this to show up, since the incubator site
 refreshes once a day (?); in the meantime, the embedded status link
 will be dead.
 It updates immediately, provided that you publish any changes.

   * The embedded content gets loaded from people.apache.org, not
 incubator.apache.org; AIUI that'll cause browsers to portend
 disaster and in some cases refuse to load the vote status. This
 should be fixed, suggestions welcome.
 The use of target=_blank causes a new window to created each time the
 link is clicked; that seems wrong.
 Yes, I just noticed that; copy-paste bug from the standalone page link,
 will fix.

 Also, it does not work in Firefox. Or Chrome. Or Opera. Or IE.
 That's caused by the the access control constraints, as I point out in
 the text you quoted. I tried circumventing that in .htaccess, but the
 incubator site config doesn't load mod_headers, so that won't help.
 However, in that case surely it ought to display an error message?

 There is some code that looks as though it tries to report the error:

 if (fragment_loader.status != 200)
 html = pContent is not available/p;
 else {
 container = document.getElementById(voter).parentNode;
 container.innerHTML = fragment_loader.responseText;
 }

 That looks wrong - why is the error written to a different variable?

Meh, another bug. Thanks for catching it and fixing it.

(Apparently I'm not at my best these days ... only this morning I
started wondering why that error message wasn't showing up. Sigh.)

-- Brane


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

Re: Incubator voting status page

[Branko Čibej]

On 01.02.2013 18:05, Daniel Shahaf wrote:
 Branko Čibej wrote on Fri, Feb 01, 2013 at 17:29:45 +0100:
 I think updating the httpd config is the more realistic option, since it
 doesn't presume a ssh tunnel between minotaur and the site server.
 The only supported way to get content to the web servers is to commit it
 to svn and have svnpubsub pull it to them.

 So, just have a cronjob on minotaur commit the changes.  You can get
 a username+password for that by asking.

Surely it doesn't make sense to commit this transient table. If I wanted
that, I'd be generating (and committing) all of content/votes.xml
instead. But I really think the voting status page should be updated
more often than once a day, hence the current architecture that doesn't
depend on incubator site updated.

I'm all for moving this from minotaur to whimsy, and do suggest we
change the incubator.a.o server config so that the votes table can be
fetched from there.

-- Brane

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

Re: Incubator voting status page

[Branko Čibej]

On 02.02.2013 16:29, Daniel Shahaf wrote:
 Branko Čibej wrote on Sat, Feb 02, 2013 at 11:01:42 +0100:
 I'm all for moving this from minotaur to whimsy, and do suggest we
 whimsy doesn't have the public-arch tree locally.

Thanks for reminding me again ... silly me.

 change the incubator.a.o server config so that the votes table can be
 fetched from there.

 Not specific enough to comment on.  (Change how?)

Either:

LoadModule headers_module /.../mod_headers.so

I've already put the following in the .htaccess file:

IfModule mod_headers.c
# Allow remote content from people.apache.org in order to fetch vote status
Header set Access-Control-Allow-Origin http://people.apache.org;
/IfModule

Or:

ProxyPass /remote/embedded-votes.html 
http://people.apache.org/~brane/incubator/embedded-votes.html

and I'll change the URL of the generated table in votes.xml.

A simple redirect will of course not work, as it triggers the same
access restriction. The proxy solution doesn't open the door as wide,
but I expect it's slightly more expensive than adding a header to the
response. Either way should work.

-- Brane


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