Re: [MENTORS] Mentor guidance document

[Ross Gardler]

Only replying because I'm called out explicitly.

Documentation does not solve the problem. If someone doesn't already "get" this 
stuff then they should not be mentoring. Having a document does not replace for 
selecting good mentors who have the time to do the job right.

It's a good effort in the broader context, but doesn't solve the problem I see 
in the IPMC (insufficient high quality mentoring coupled with too much 
application of rules in the process). The proposed doc is interesting but it's 
just more words, We need more action.

How would I solve the problem? If I were championing another project into the 
ASF I would carefully select mentors, just as I have in the past. I'd select 
those who don't need the above document and who I'm confident will pay 
attention and be constructive. I'd then work with those mentors and the 
community to ensure people coming through the process are equipped to help me 
on the next project I champion.

This is not new. It's how we setup the Incubator in the first place. But over 
the years it has become a machine rather than personal relationships. More 
words about the design of the machine won't change this.

I don't mean to say the effort you are putting in is wasted effort. Clarity in 
what is expected can help the podlings, but I don't see how this can really 
help those people I would already trust to be good mentors i.e. People who have 
a vested interest in the success of the project and already know how to apply 
the Apache Way to new communities so that they might flourish in their own way.

Ross


---

Sent from my phone, you know what that means - sorry


From: Justin Mclean 
Sent: Saturday, August 17, 2019 6:26:32 PM
To: general@incubator.apache.org 
Subject: Re: [MENTORS] Mentor guidance document

Hi,

I've had hoped I'd get more of a response to the mentor guidance documentation 
I suggested. Perhaps it got lost in the other noise?

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINCUBATOR%2FMentor%2BGuidancedata=02%7C01%7C%7C0e716c1bb8a74438cd0108d7237b24aa%7C84df9e7fe9f640afb435%7C1%7C0%7C637016884106582384sdata=9v85p9zRNDFHPp3yJgpVp7GUz%2F0NDNvC8vQuZjT4X50%3Dreserved=0

Jim and Ross, you have recently stated that you are concerned about the erosion 
of our values and principles. It would be great to see your input on this. If 
you have other idea one how these values can be better passed to incubating 
incubation it would be great to hear.

I also welcome other IPMC members who have experience and can offer some advice 
to other mentors.

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

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Ross Gardler]

Here's an idea... The IPMC focuses on supporting mentors to do their job rather 
than forcing project developers and their mentors to jump through arbitrarily 
defined hoops.

That means stay out of the way until the mentor asks for a graduation vote. The 
IPMC doesn't need to enforce policy of any kind, except at the point of 
graduation. Policy is set and enforced by VP Legal, infra marketing, trademarks 
etc. The mentor can work directly with them as necessary.

I know holding mentors accountable is a tough job in itself, but if we quit 
accepting vanity mentors and instead focus on supporting mentors who have a 
personal interest in the success of the podling it shouldn't be too hard.

When things change for individuals and they can no longer be good mentors then 
the IPMC  needs to make it a priority to help find a new, truly dedicated 
mentor. It's a problem that needs to be solved, but let's worry about that when 
it's actually a problem rather than a hypothetical one.

Ross

---

Sent from my phone, you know what that means - sorry


From: Justin Mclean 
Sent: Tuesday, August 13, 2019 3:04:46 PM
To: general@incubator.apache.org 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

Hi,

> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
> the podling is fully compliant with Apache Release Policy and goes through 
> the usual process. Abiding by the Apache Release Policy would remain a 
> Graduation Requirement.

I’ll note not a single podling has asked for a [REVIEW].

> So, we treat these releases as not fully approved the same way we treat 
> Binary Conveniences.

They are not the same as binary conveniences, as they are derived from a voted 
on approved release. Thinking about (F) if they are not official releases could 
a podling:
a) Call them Apache releases? (Not doing may have a number of implications 
including naming of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what 
would be required to make it clear they are not approved releases?

We might want to check with branding and legal and get their input on this.

My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at 
the releases or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a 
community proposed graduation and it found it’s releases have serious issue?

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

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Ross Gardler]

I see I was volunteer... OK let's do it.

---

Sent from my phone, you know what that means - sorry


From: David Nalley 
Sent: Monday, August 12, 2019 8:31:29 PM
To: general@incubator.apache.org 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

>
> I'd like to see the IPMC get out of the way of the podlings' releases. I
> see no reason for us to be a gate, and many more reasons to back off and
> let podlings get their work done.
>

I strongly agree with your sentiment, even if I differ with your tactics a bit.

I think that they are releases (e.g. we the foundation accrues a bit
of risk when releasing, and in turn shield our contributors from risk
as we've promised) Obviously we aren't claiming that they are perfect
apache releases that meet the minimum apache guidelines for
cleanliness) and that we should recognize that risk by having the fact
that they are incubating clearly in the name. (Oh wait, we already do
that.) We also have the new disclaimer in there for good measure.

This, IMO, exposes the ASF to a very (teensy weensy) slight increase
in risk, but for a much greater community gain. We have DMCA safe
harbor process to shield us from a good deal of the risk. The podling
gets to move faster, and hopefully learn and grow faster in the
process.

Failure isn't the problem, IMO. In fact we should be pushing people to
fail faster, so that each time the release gets a little better, and
each time the community grows, and more people understand the
processes and problems.

Greg - I propose that you, Ross (sorry for volunteering you), and I
pick an incubating project in need of mentor attention and make this
as streamlined as we can. Let's focus on educating and enabling and
not gatekeeping. Let's prove out the concept and stop beating this
poor horse so much. :)

--David

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

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Ross Gardler]

When I used to do endless apache way talks I used to say "if you are using an 
Incubator project expect to invest in both engineering and legal, but once a 
project is a TLP your legal can reduce and engineering becomes about your use 
rather than community progrwe towards TLP"

In other words Jim is right IMHO

---

Sent from my phone, you know what that means - sorry


From: Dave Fisher 
Sent: Tuesday, August 13, 2019 9:22:26 AM
To: general 
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

Hi Ted,

This subthread as named by Greg is really about this:

> On Aug 11, 2019, at 5:56 PM, Greg Stein  wrote:
>
> See further below for an unfortunately trimmed thread. A couple paragraphs
> that I wrote early-thread are important to add:
>
> 
> Option (F): stop calling them official ASF releases, which means PMC votes
> are not required.
> ——

I am for option (F) with the addition of Myrle’s [REVIEW] until such time as 
the podling is fully compliant with Apache Release Policy and goes through the 
usual process. Abiding by the Apache Release Policy would remain a Graduation 
Requirement.

So, we treat these releases as not fully approved the same way we treat Binary 
Conveniences.

I think that this pattern grows the PPMC into a true PMC better by expecting 
that licensing issues which require vigilance become part of the Project’s DNA 
in a more organic way.

Regards,
Dave

> On Aug 13, 2019, at 9:09 AM, Ted Dunning  wrote:
>
> Dave,
>
> I understand the problem with long delays. What I don't understand is how
> the proposal changes any of that.
>
> 90% of project release still require additional votes. How will that change?
>
> Every other change is peripheral.
>
>
>
> On Tue, Aug 13, 2019 at 8:37 AM Dave Fisher  wrote:
>
>>
>>
>>> On Aug 12, 2019, at 1:34 PM, Ted Dunning  wrote:
>>>
>>> On Mon, Aug 12, 2019 at 11:10 AM Dave Fisher > w...@apache.org>> wrote:
>>>


> On Aug 12, 2019, at 10:02 AM, Ted Dunning 
>> wrote:
>
> On Mon, Aug 12, 2019 at 9:24 AM Jim Jagielski  wrote:
>
>>
>>
>>> On Aug 12, 2019, at 10:44 AM, Ted Dunning 
 wrote:
>> ...
 "The Apache Podling Foo has voted on releasing Foo 1.2.2 (url and
 pointers here). We have 3 (or more) binding votes from mentors. We
>> are
 giving the IPMC and additional 72 hours to vote on said release."

>>>
>>>
>>> This is good in theory, but as Justin has pointed out, 90% of podling
>>> releases don't have enough mentor votes to follow this path.
>>>
>>> The 10% that do have enough votes can easily follow this process.
>>
>> Then the ones that don't have enough mentors still require the 3 +1
>> binding votes. The idea is that if the podling already has it, then
>> the
>> IPMC "vote" is more procedural than anything else. If they don't, then
>> either the mentors need to step up or the IPMC fills in the gap.
>>
>> The goal is to avoid having the Incubator be a gate-keeper.
>>
>
>
> I don't understand how this is all that different from what we have
>> now.
 If
> three mentors (and thus IPMC members) vote yes, then opening up the
>> vote
 to
> include the IPMC is just like what you said, "we have three votes
>> already
> and unless somebody points out something heinous, this is going to be a
> release". Whether the IPMC is a gatekeeper or a rubber stamp in these
 cases
> is a tiny matter of nomenclature because the effect is typically a
>> rubber
> stamp (although some of these releases are examined carefully and
>> things
> turn up).
>
> In the large majority of cases, the Incubator is definitely not a
> gatekeeper. If anything, the non-mentor IPMC votes are enablers that
 allow
> a release to go forward when it would otherwise fail.

 A week or two (an uncertain time) to do release votes as opposed to what
 may already be a significant increase to a minimum 3 days will FEEL
>> like a
 closed GATE. (For example Zipkin really felt gated.)

>>>
>>>
>>>
>>> Dave,
>>>
>>> I don't understand your point.
>>
>> My point is that what you describe below are the ideal results. We all
>> know that while the podling itself can do release votes in 72 hours it
>> often takes the IPMC much more than 72 hours to vote. It used to be weeks
>> and has improved significantly to where most podlings can be done inside of
>> one week.
>>
>> The timing and uncertainty of this is too much for some previously
>> established communities. For instance I think that this indeterminate lag
>> is one of the causes that made Zipkin a poor fit here.
>>
>> We've relaxed DISCLAIMERs. Should we wait to see if this improves the
>> situation, or should we do another small step and essentially follow
>> Myrle’s Review plan[1] for all general@ votes?
>>
>> Regards,
>> Dave
>>
>> [1]
>> 

Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

[Ross Gardler]

Thanks Greg, I am fully in support of your position here.

The ASF is supposed to make it easier for developers to develop. It is not 
supposed to be creating red tape to guard the entrance to the hallowed halls.

Ross


From: Greg Stein 
Sent: Sunday, August 11, 2019 5:56 PM
To: general@incubator.apache.org
Subject: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)

See further below for an unfortunately trimmed thread. A couple paragraphs
that I wrote early-thread are important to add:


Option (F): stop calling them official ASF releases, which means PMC votes
are not required.


> In that case voting would not be required and they wouldn’t have to follow
> ASF policy.


Right.


> If they are not official releases then we probably can’t release or
> distribute them on ASF infrastructure.


I see no problem with using our infrastructure to distribute F/OSS
materials. Why would the Foundation want to be against that? If it is
labeled properly, then ... roll with it. We distribute a *ton* of stuff
that wasn't produced by the ASF. We incorporate that stuff into a larger
work, but it isn't "ours". Yet we put it onto our servers.

Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe
somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use
it ... but John and Jane and Joe certainly want to, and *can*. Isn't that
our goal?


I see no problems with the purported "risk" mentioned below. Would some
mis-licensing occur? Likely. Is it material to the Foundation's mission?
Nah. What if something appears on our servers without a clear F/OSS
license? Does John or Jane care? Nopes. But we fix it in a future release.
Move along, everybody is happy.

I'd like to see the IPMC get out of the way of the podlings' releases. I
see no reason for us to be a gate, and many more reasons to back off and
let podlings get their work done.

Cheers,
-g

On Sun, Aug 11, 2019 at 7:46 PM Greg Stein  wrote:

> On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> > I see no problem with using our infrastructure to distribute F/OSS
>> > materials. Why would the Foundation want to be against that? If it is
>> > labeled properly, then ... roll with it.
>>
>> It often isn’t labelled properly.  There’s a reasonable risk that some of
>> what would be placed there and distributed isn’t actually F/OSS.
>
>
> And what would be the blowback of something on our server with incorrect
> information? Very little. Mostly, we'd just move on. Maybe we delete it.
>
>
>> I can point you to several example of this. I’m not sure how the
>> incubator (or the board) would feel about that risk, so that would be
>> something we would be need to consider further. Also
>
>
> Welp. Then I will pose that question, rather than this endless
> pontificating about "risk".
>
>
>> while Jane and John may be fine with that, a lot of companies that use
>> Apache releases may not be.
>>
>
> I already acknowledged that. Many people could use software regardless of
> its licensing. The license typically only matters in *redistribution*
> scenarios. Things like the AGPL affect *usage*, but that is very, very
> atypical. I'd think 99% of downstream could use our software, even with
> gummed-up licensing.
>
>
>> > You're conflating *learning* with *releases*. These can be handled
>> separately.
>>
>> How exactly?
>
>
> You're saying that releases are the control point to learning. I say just
> let the releases go.
>
> You want to teach? Then you can use the releases like "that wasn't good.
> next time: do A and B". Over time, releases will get fixed. But the IPMC
> should not have to manage the releases.
>
> Cheers,
> -g
>
>

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

Re: Podlings, the Incubator, relationships and Apache

[Ross Gardler]

Jim said "Let's also recall that the origin genesis of the Incubator was NOT to 
provide legal oversight, but rather education and guidance into The Apache Way"

I say... HEAR! HEAR!

Get Outlook for Android


From: Jim Jagielski 
Sent: Tuesday, July 2, 2019 4:36:02 AM
To: Incubator General
Subject: Re: Podlings, the Incubator, relationships and Apache



> On Jul 1, 2019, at 1:45 AM, Alex Harui  wrote:
>
> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something an 
> ASF release in order to place that release under the legal protection of the 
> ASF.  ASF releases may have policy non-compliance issues.  No TLP can decide 
> on its own to never comply with policy.  But the business decision of the 
> costs of delaying a release to correct non-compliance vs risks of 
> distributing a release with any non-compliance is up to the TLP.  VP Legal 
> will assert a risk profile for any non-compliance and VP Legal or any ASF 
> Member or PMC Member should try to stop a release if a TLP decides to 
> distribute something highly risky.   But it is up to any TLP.  Including the 
> IPMC.  And so the Incubator can do whatever it wants within limits.  Any of 
> us should protest if the IPMC starts allowing releases with high risk.  But 
> with the disclaimer and -incubating suffixes, the risk of many non-compliance 
> issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by the 
> above.  IPMC members could drop in on the podling vote thread.  Podlings with 
> 3 active mentors that vote on the podling's vote thread could be deemed 
> sufficient.
>

Although not a "real" PMC, we do need to provide legal protection for each PPMC 
and distributing releases is the time that most legal considerations "kick in" 
as it were. So we need a clear "paper trail" of approvals for that PPMC to 
enjoy the legal protection the foundation exists to provide. The IPMC vote, 
since the IPMC is, in fact, a true PMC, provides that legal provenance such 
that, should anything untoward happen, we can clearly show to outside legal 
entities corporate provenance without having to try to explain the intricacies 
of podlings, and PPMCs and PMC and et.al. :-)

Let's also recall that the origin genesis of the Incubator was NOT to provide 
legal oversight, but rather education and guidance into The Apache Way (TAW). 
Back then we had way too many projects that were TLP status that lacked even a 
basic awareness of TAW, and the board, rightfully, considered that a huge 
problem (this started with the mismanagement of the Jakarta project, which 
tried to create a sub-foundation within the ASF such that the Jakarta PMC was 
basically the "board" of that "foundation"... as these projects spun out, 
problems aplenty ensued). And so the Incubator was created to handle that 
problem.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ross Gardler]

Myrle makes a good point. As a mentor (is been a long time though) I tried to 
cast my vote after there were at least 3 views from the community. Once I saw 
the ppmc catching issues I was missing, or I was simply ratifying their view, 
it was time to graduate.

The IPMC should have nothing to do with it, other than as a backstop for absent 
mentors.

Interested IPMC members can join the community like everyone else. They are not 
some privileged group that gets special treatment.

Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking 
IPMC to vote

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
>  wrote:
> > ...Maybe the PPMC and IPMC vote could run in parallel...
>
> I think the reason for having two votes is to give an opportunity for
> mentors to catch issues in the first one without bothering the IPMC.
>

The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ross Gardler]

Sure, policy is "Release votes SHOULD remain open for at least 72 hours."

The reasons for the SHOULD have been outlined already and should be well known 
to anyone who is in a podling since it's core to everything we do. I would have 
hoped champions would have explained this before even making the proposal. Not 
that it does any harm to repeat it.

Same goes for properly documenting what your +1 means. In the ASF +1 does not 
mean YES it means yes AND I have done what is necessary (in the case of 
indicating appropriate due diligence) or yes AND I will help make it happen (in 
the case of approving an action plan). Again, no harm in repeating this often.

It might be useful to give an example of where there is no need for a release 
vote to go 72 hours. A well run project will seek to have their code in a 
releasable state at all times. That means reviewing for IP, test coverage, 
backward compatibility breaks etc. on every commit. In the case of a minor 
point release or a bug fix release such projects MAY choose to release when 3 
+1s are received. After all, if an issue is discovered on the 73rd hour a fix 
can be committed and a new release voted started immediately without creating 
additional work for anyone.

Ross


From: Justin Mclean 
Sent: Monday, April 1, 2019 3:42 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking 
IPMC to vote

Hi,

When Ross wrote “72hrs or 3 +1” I think he was using shorthand, not
> intending to rewrite foundation policy.
>

Sure I thought so as well, but other newer people here might not of been
aware of it.

Thanks,
Justin

>

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ross Gardler]

72 hours is a guide. As long as your project community is agreeable you can say 
"72hrs or 3 +1".



Get Outlook for Android<https://aka.ms/ghei36>


From: Adrian Cole 
Sent: Sunday, March 31, 2019 9:26:08 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking 
IPMC to vote

I have a related question. In Zipkin (incubating) last release of one of
our projects, we had 3 IPMC +1 votes prior to the formal verification vote.
Then we basically just waited 72hrs anyway with no additional votes but it
didn't matter as we had what we needed (another came later but still) [1]

If a project already has 3 IPMC members active verifying and voting.. it
might feel a bit tedious to delay a release an additional 3+ days
especially if there is no additional feedback.


Not sure the answer here, but I hope the situation is relevant to the
thread. For example, should same rules apply when there are no additional
IPMC votes needed from what is carried over from the podling vote?

-A

[1]
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F6e26ccaecba70a5cde1f808d82499701562f370441067b96ca65f09a%40%253Cgeneral.incubator.apache.org%253Edata=02%7C01%7C%7Cf3f98ab49c294fdee58408d6b65a22eb%7C84df9e7fe9f640afb435%7C1%7C0%7C636896895573897795sdata=oQg4R6ms2IRkfoGdVAf54vUrhXLaq9DIbmk%2F4SzwTvE%3Dreserved=0

On Mon, Apr 1, 2019, 11:15 AM Ross Gardler  wrote:

> Just like so many things, this is how it used to be. In fact, back in the
> day the only time the IPMC was asked to vote was when there were not enough
> mentor votes.
>
> If you look at all the podlinga I've mentored I have only ever asked for
> an IPMC vote on two occasions (that I recall). One because I had absent
> mentors (the project never graduated due to lack of success as a community)
> and one because it was a very large and complex code base and we asked for
> extra eyes on the first release.
>
> Every other time the community worked with mentors. Once we had the votes
> we notified the IPMC that the vote had passed and moved on.
>
> Requiring an IPMC vote is akin to the board voting on all TLP releases. It
> should be stopped. The IPMC are facilitators not gate keepers.
>
> Individual IPMC members can join the podling communities if they wish to
> participate. Why are podlings and mentors answering to the IPMC by default?
>
> I know the standard answer is because mentors sometimes get too busy.
> Sure. If it happens every release is a problem and having to ask for an
> IPMC vote highlights the problem.
>
> I realize this proposal does not go this far, I'm +0 for the proposal as a
> step in the right direction, but it doesn't go far enough in my opinion.
>
> Ross
>
> Get Outlook for 
> Android<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=02%7C01%7C%7Cf3f98ab49c294fdee58408d6b65a22eb%7C84df9e7fe9f640afb435%7C1%7C0%7C636896895573897795sdata=pXkL0wr7fNysnARTzfPwP9pLFRmeJdpIQxFo8Y5Vyuo%3Dreserved=0>
>
> 
> From: Craig Russell 
> Sent: Sunday, March 31, 2019 8:30:35 PM
> To: Incubator
> Subject: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking
> IPMC to vote
>
> This is a proposal to recommend that all Mentors SHOULD vote on podling
> releases prior to sending the release for a vote to the IPMC.
>
> This is not a MUST, since there are many good reasons why a mentor might
> be unable to perform the checks needed to vote. We are volunteers after all.
>
> But if this proposal is adopted, it will minimize the occurrences of a
> podling desperately asking for someone, anyone, on the IPMC to please vote.
>
> It should also minimize the number of podling releases that are shot down
> in the full IPMC vote because of something that a Mentor is likely to catch.
>
> Thanks for your consideration,
>
> Craig
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ross Gardler]

Just like so many things, this is how it used to be. In fact, back in the day 
the only time the IPMC was asked to vote was when there were not enough mentor 
votes.

If you look at all the podlinga I've mentored I have only ever asked for an 
IPMC vote on two occasions (that I recall). One because I had absent mentors 
(the project never graduated due to lack of success as a community) and one 
because it was a very large and complex code base and we asked for extra eyes 
on the first release.

Every other time the community worked with mentors. Once we had the votes we 
notified the IPMC that the vote had passed and moved on.

Requiring an IPMC vote is akin to the board voting on all TLP releases. It 
should be stopped. The IPMC are facilitators not gate keepers.

Individual IPMC members can join the podling communities if they wish to 
participate. Why are podlings and mentors answering to the IPMC by default?

I know the standard answer is because mentors sometimes get too busy. Sure. If 
it happens every release is a problem and having to ask for an IPMC vote 
highlights the problem.

I realize this proposal does not go this far, I'm +0 for the proposal as a step 
in the right direction, but it doesn't go far enough in my opinion.

Ross

Get Outlook for Android<https://aka.ms/ghei36>


From: Craig Russell 
Sent: Sunday, March 31, 2019 8:30:35 PM
To: Incubator
Subject: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC 
to vote

This is a proposal to recommend that all Mentors SHOULD vote on podling 
releases prior to sending the release for a vote to the IPMC.

This is not a MUST, since there are many good reasons why a mentor might be 
unable to perform the checks needed to vote. We are volunteers after all.

But if this proposal is adopted, it will minimize the occurrences of a podling 
desperately asking for someone, anyone, on the IPMC to please vote.

It should also minimize the number of podling releases that are shot down in 
the full IPMC vote because of something that a Mentor is likely to catch.

Thanks for your consideration,

Craig

Craig L Russell
c...@apache.org


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

Re: List of Projects that went straight to Top Level Projects

[Ross Gardler]

This was an outcome of the last time the IPMC processes were challenged. 
Basically the board agreed that in cases where the initial PMC consisted of 
plenty of existing experienced ASF people there was no need for incubation.

There was never an intention of going straight to TLP if there was not 
sufficient experience in the PMC to start with.

Ross


From: Geertjan Wielenga 
Sent: Sunday, March 31, 2019 4:51 AM
To: general@incubator.apache.org; sha...@apache.org
Subject: Re: List of Projects that went straight to Top Level Projects

Ah, OK. I’d be interested in the outcome of that research too. I don’t
think it’s common to skip incubation and I’m sure a lot would not be
learned by skipping it.

Gj

On Sun, 31 Mar 2019 at 13:44,  wrote:

> Hi Geertjan
>
> Thanks for the email and I'm not thinking of doing it at all.
>
> I'm planning to do some research for on the embedding of ASF culture and
> incubator is one of the main way this happens. Sometimes as in the cases
> of the projects I mentioned, the process is bypassed so one of the
> things I'd like to investigate is the effect of missing out on
> incubation. My question about the list of projects that went to TLP was
> more about making sure I have as much data as possible to base my
> research on.
>
> Thanks
> Sharan
>
>
> On 31. 03. 19 13:36, Geertjan Wielenga wrote:
> > I would highly recommend that you don’t do this. What would be the reason
> > to go straight to TLP? There’s a lot to learn and many mistakes to make,
> > and speaking from experience, it is best to learn and make mistakes in
> the
> > incubator, which is precisely its purpose.
> >
> > Gj
> >
> > On Sun, 31 Mar 2019 at 13:28, Sharan Foga  wrote:
> >
> >> Hi All
> >>
> >> Does anyone know if there is a list of projects that bypassed
> incubation?
> >> For example - I know a couple of projects Royale and Kibble that went
> >> straight to TLP. Is there a list anywhere for all projects like this?
> >>
> >> Thanks
> >> Sharan
> >>
> >> -
> >> 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: Voting on releases with serious unaddressed issues

[Ross Gardler]

"What is important is tat it has been addressed and the podling is fixing the 
issue" - big +1000

Thank you to everyone for doing the right thing here. Including Justin for 
agreeing to change his vote - I think that was the right thing to do even 
though, on this occasion, he could have cited my point #1 (if VP Legal says 
it's a blocker then it's a blocker). 

Ross


From: Justin Mclean 
Sent: Sunday, March 31, 2019 3:54 AM
To: general@incubator.apache.org
Subject: Re: Voting on releases with serious unaddressed issues

Hi,

> For the record, no. No. It was never simply called theft. These files were
> part of the donation received from Oracle. We did not add these files in
> any way in Apache and simply received them as part of the donation. We have
> now removed them, so that this kind of stupid accusation can cease and
> since we didn’t care about them at all in the first place.

Part of all projects path to graduation is checking IP provenance, please don’t 
take that that you did the theft but perhaps someone did it before you did, a 
poor analogy is "receiving stolen goods". Stuff like this is often an 
accidental and unintentional, some internal developer copies something to use 
in a test that they think will never be public. Until that is it becomes open 
source. I have seen far more numerous and far more serious infringements of 
copyright in other codebases donated by other large companies. What is 
important is tat it has been addressed and the podling is fixing the issue

It could be far worse, for instance [1] (and they also have a script for hamlet 
they want to talk to you about).

Thanks,
Justin

1.https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute
-
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: Voting on releases with serious unaddressed issues

[Ross Gardler]

Opinions were asked for. I gave mine.

I have tried to do it before and been squashed repeatedly because my opinion is 
not broadly supported. I should not have said board must as it has been brought 
here recently and did not find support.

I don't a agree that the proposal for the IPMC to be facilitators rather than 
gatekeepers is a suggestion. It's what the IPMC was set up to be. It's not what 
it is, but it's what it was intended to be (and was for quite some time).

Your are right to call me or on do it or get out, if I choose to champion or 
mentor another project here I will do it within that project. That is, as a 
mentor /champion I will ensure the project did not need the IPMC to vote and 
this this whole discussion would not be necessary, for that project.

My actions will match my recommendations.

Get Outlook for Android<https://aka.ms/ghei36>



From: Myrle Krantz
Sent: Saturday, March 30, 3:00 AM
Subject: Re: Voting on releases with serious unaddressed issues
To: general@incubator.apache.org


On Sat, Mar 30, 2019 at 9:11 AM Ross Gardler  wrote:

> As for not enough votes i refer you to Roy's suggestion on board@.
> Essentially votes don't need to be from IPMC members.
>

Hey Ross,

A.) That was a suggestion and not a statement about how the incubator
currently operates.  If you want to change the way the incubator currently
operates, please put it up for discussion.  Preferably on a public list.
B.) While the person you're replying to can see Roy's suggestion, not
everyone on this list can.  Not even all of the IPMC members can in fact.
If you want to make a suggestion to the way we work in the incubator,
please include both the suggested change AND the arguments where they can
be seen by the IPMC.  Who the idea or the arguments are originally from
isn't directly relevant to the merits of the proposal, but in general I
wouldn't appeal to Roy's authority here, since he hasn't, to my knowledge,
given permission to put his words in public.

Best Regards,
Myrle

Re: Voting on releases with serious unaddressed issues

[Ross Gardler]

For 2, yes I'm saying exactly that. It's long been an expectation in apache 
that a -1 be accompanied by a willingness to help fix the problem. There are a 
few exceptions, such as releases. That's why I have #1 of something is not 
approved by legal and infra then a -1 reflects that. If the -1 is ticking boxes 
on a formal process then I don't see that as constructive, unless accompanied 
by a willingness to help.

Awareness is good. For none blocking items a +1 accompanied by a recorded issue 
about something that must be approved before graduation is the way to go if one 
does a check but didn't want to help fix things.

As for not enough votes i refer you to Roy's suggestion on board@. Essentially 
votes don't need to be from IPMC members.

Get Outlook for Android


From: Justin Mclean 
Sent: Friday, March 29, 2019 10:32:24 PM
To: general@incubator.apache.org
Subject: Re: Voting on releases with serious unaddressed issues

Hi,

> 1) If VP Legal or VP Infra says any of the issues are blockers then the 
> podling cannot do a release

I guess they well need to clarify that then, but AFAIK an an ex VP legal has 
said this, and VP infra has stated this for the exact issues mentioned in this 
release.

> 2) If IPMC members want to become contributors and help fix the problems with 
> pull requests,  or mentors (meaning real mentors not just folks pointing out 
> problems, then they should get started. As active members of the community 
> those individuals will have the right to vote -1 on a release.

So are you saying that IPMC members vote are only valid for +1 votes on 
podlings they are not actively involved in and their -1 votes are invalid? The 
risk I see there is IPMC votes when needed just become just a rubber stamping 
exercise.

> 3) If the podling is unable to gather three +1s among their active community 
> then they won't be able to do a release so the conversation is moot

Well in this case here that happened (they only had one binding vote) and they 
asked the IPMC to vote on it. Some podlings, for a number of reasons, are not 
going to be able to find 3 active IPMC members in their project to vote on 
every release. (Although I'm surprised in this case given who the mentors are).

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

Re: Voting on releases with serious unaddressed issues

[Ross Gardler]

Three comments, each of which I phrase as my opinion on the correct way to do 
this. Each comment is independent from the other:

1) If VP Legal or VP Infra says any of the issues are blockers then the podling 
cannot do a release

2) If IPMC members want to become contributors and help fix the problems with 
pull requests,  or mentors (meaning real mentors not just folks pointing out 
problems, then they should get started. As active members of the community 
those individuals will have the right to vote -1 on a release.

3) If the podling is unable to gather three +1s among their active community 
then they won't be able to do a release so the conversation is moot

Ross


From: Justin Mclean 
Sent: Friday, March 29, 2019 7:24 PM
To: general@incubator.apache.org
Subject: Voting on releases with serious unaddressed issues

Hi,

The  Netbeans RC is an interesting one as they:
- Have made several releases before.
- Have been given advice from the IPMC on serious issues and what to fix.
- Looks like nothing has been done to correct those issues.

Now I know we’re trying to be more lenient on releases but we still have to 
draw the line somewhere and this is not their first release. The the binary in 
source code, license issues copyright issues on the cute cat and rabbit photos 
[1] probably mean that they cannot put that release in the ASF distribution 
area even if they do get 3 +1s without legal and infra approval.

What do other IPMC members think?

Thanks,
Justin

1. Curiously this is the second time I’ve vote -1 because of a cat photo taken 
by a professional photographer has been included in a source release
-
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: A smaller IPMC

[Ross Gardler]

I think this thread misses the point of the original observation.

Firstly, I've not seen anyone suggest that removing inactive IPMC members will 
make any difference. What I've seen is a suggestion that active IPMC members on 
general@ should be expected to be on the private list.

While there aren't many conversations over there. When there is one it is 
important.

Secondly, I think the framing of #4 (which I agree with in the context of this 
thread, given the above observation) incorrectly identifies the "real" problem. 
While inactive mentors a problem for individual podlings I don't believe they 
are the cause of the inteference the IPMC can display when it comes to things 
like podling releases.

In other words I consider this whole thread a distraction.

Get Outlook for Android


From: Kenneth Knowles 
Sent: Thursday, March 7, 2019 7:49:29 PM
To: general@incubator.apache.org
Subject: Re: A smaller IPMC

+1 for #4 noop, at least until there's evidence of a problem.

Kenn

On Thu, Mar 7, 2019 at 6:27 PM Woonsan Ko  wrote:

> On Thu, Mar 7, 2019 at 6:33 PM Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > It’s been suggested that the IPMC is too large, what do other IPMC
> members think might be a way to address this?
> >
> > Please discuss and indicate +1 what you would think would help, you can
> vote for more than one.
> >
> > Some suggestions:
> > 1. Ask all inactive IPMC if they want to continue being on the IPMC and
> see who steps down. Being inactive they are probably not following this
> list so we need to identify and send each one email them personally.
> > 2. There were some questions around merit raised, remove all IPMC
> members who were not on the initial proposal and who were voted in. Those
> left on the IPMC vote back in those who are currently active.
> > 3. Get rid of all IPMC members, and vote (with ASF members vote being
> binding - not sure how else it could be done?) currently active ones back
> in.
> > 4. Do nothing as this is not actually a problem but instead address
> other underlying issues. e.g. lack of mentor engagement.
>
> +1 to my modified version from #2 (and 0 to the others as I don't
> think they will help a lot):
> "Remove all IPMC members who were not on the initial proposal and who
> were voted in. Those left on the IPMC vote for those, as members, who
> can recruit, guide mentors, and review podling graduations, and they
> also vote for those, as mentors (committers), who have ever been
> active mentors for podlings."
>
> Mentors are committers: if someone starts contributing in this
> community, they are to be recognized and invited to a mentor
> (committer) in this project; if they contribute more for the community
> consistently, they are to be invited to a IPMC member. In smaller
> IPMC, IPMC members focus more on helping/guiding mentors and reviewing
> graduations in various aspects, and mentors focus more on detail
> issues in podlings, providing enough overview and information to IPMC.
> I think this will make it a fairer merit-earning game, to new comers
> getting helps from mentors and (graduation and/or high-level) reviews
> from members, watchers considering to help, mentors eager to help
> graduations, more focused members, ...
>
> >
> > Also re point 2 do you think we should drop that ASF members can
> automatically get IPMC membership and change it to requiring a vote by the
> IPMC? It’s has always seem odd to me that this is the case. We’ve recently
> voted more people in that we’ve had requests from ASF members.
>
> +1 to always be voting, whether they are ASF members or not, like other
> PMCs.
>
> >
> > Any other sugestions?
> >
> > Options 2 and 3 may cause some issues around mentors, but if they were
> not active then I guess it’s no big loss.
>
> My modified version includes all active people as mentors (committers)
> at least, so there's no loss as well.
>
> Regards,
>
> Woonsan
>
> >
> > And any suggestions on level of activity? Such as:
> > - Emailed the list in the last year.
> > - Reviewed at least one release in that time.
> >
> > It’s already been determined that some (about 15%) of the less than
> active PMC members (out of the 100 odd that are not signed up to the IPMC
> private list) do help out infrequently but that help is very useful. That
> may also apply to other inactive IPMC members, so I would suggest the bar
> for what consider active be kept low.
> >
> > Thanks,
> > Justin
> > -
> > 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] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler]

Projects are free to set their own bylaws. As long as the community as a whole 
agree to removal of inactive members then they can do that. Though merit does 
not and should not expire.

It is my opinion, and the opinion of many others, that keeping busy work to a 
minimum is important to the health of a community. Removing inactive committers 
is busy work. If they come back in x months and provide new patches, bringing 
them back as committers is busy work. If their commit bit remains active but 
they never commit again is not busy work.

Note, at the foundation level a committer remains recognized (their apache.org 
account remains active, for example).

Ross

Get Outlook for Android<https://aka.ms/ghei36>


From: Dmitriy Pavlov 
Sent: Wednesday, March 6, 2019 12:08:49 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy 
general@ subs check (was:  introduce "[DISCUSS]" threads for podling ... 
release candidates))

Hi Ross,

Thank you for your reply. Apache Ignite PMCs do not support this idea, so
inactive PMCs will be still there.

But still, it is not clear for me in general, why following
projects/guidelines contains removal procedure for Committer PMC:
- 
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmnemonic.apache.org%2Fdevelop%2Fbylaws%2Fdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=qq8L7D0w7Au6yursya5M%2BEVHEDbSMQqVMTYQ1hAEFYk%3Dreserved=0
  after 6 months of inactivity
both PMC and Committer status may be removed.
- Default Incubator guidelines
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.apache.org%2Fincubator%2FDefaultProjectGuidelinesdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=ctQ%2BmlgRbSXVYe5tEQdUhLSZIugzYgVZiPw5nYPna%2FI%3Dreserved=0
 It contains
procedures of consensus-based removal, - it is ok to remove for Incubator?
is it ok for TLP?

If both PMC & Committer roles are merit-based, and merit does not expire,
how it even possible to remove TLP committer/PMC (excepting some extreme
cases)?

This question is not only mine, but it is also often asked and I would like
to know the answer.

Sincerely,
Dmitriy Pavlov

ср, 6 мар. 2019 г. в 18:47, Ross Gardler :

> Merit does not expire. People who are not active today should be able to
> become active tomorrow without having to jump through approval hoops.
>
> In projects there is no concept of emeritus PMC. Here in the IPMC the
> issue is very different. Most people earn merit transitively - become a
> member, become a mentor, become an IPMC member. It's different.
>
> Please don't use what is being discussed here as being transitive to a PMC
> based entirely on directly earned merit.
>
> Get Outlook for 
> Android<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36data=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=E4BNgsdPokj3UCHZlKdjP60qXF7SZAybTN6gLWUVN9s%3Dreserved=0>
>
> 
> From: Dmitriy Pavlov 
> Sent: Tuesday, March 5, 2019 4:46:09 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was:  introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> I absolutely agree with Greg Stein. I can't find any single reason to keep
> unsubscribed members of IPMC in the roster. These members can be asked to
> subscribe, and if they do, then ok; if don't - it is perfectly ok to
> remove.
>
> Similarly, I don't see reasons for having inactive TLP PMC members. I've
> suggested the same change in Apache Ignite, but I don't clearly understand
> why remained members resisting this change.
>
>
> пн, 4 мар. 2019 г. в 09:58, Ross Gardler :
>
> > That's right Greg. And since we are filling in gaps for people...
> >
> > I was originally against the pTLP concept (though I supported the
> > experiments) or any of the derivatives that came from it. I think I have
> > changed my position. Largely based on the fact that every single project
> > I've discussed the ASF with in the last 3-5 years has had a very
> inaccurate
> > perception of how the ASF works. I believe a large part of this is due,
> in
> > part, to the issues being discussed in this thread.
> >
> > I do not understand how a foundation which prides itself in having very
> > little bureaucratic red tape can be seen as having so much red tape. The
> > projects I talk to just want to build software. It used to be that the
> ASF
> > focused on running the legal and ope

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler]

Merit does not expire. People who are not active today should be able to become 
active tomorrow without having to jump through approval hoops.

In projects there is no concept of emeritus PMC. Here in the IPMC the issue is 
very different. Most people earn merit transitively - become a member, become a 
mentor, become an IPMC member. It's different.

Please don't use what is being discussed here as being transitive to a PMC 
based entirely on directly earned merit.

Get Outlook for Android<https://aka.ms/ghei36>


From: Dmitriy Pavlov 
Sent: Tuesday, March 5, 2019 4:46:09 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy 
general@ subs check (was:  introduce "[DISCUSS]" threads for podling ... 
release candidates))

I absolutely agree with Greg Stein. I can't find any single reason to keep
unsubscribed members of IPMC in the roster. These members can be asked to
subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.

Similarly, I don't see reasons for having inactive TLP PMC members. I've
suggested the same change in Apache Ignite, but I don't clearly understand
why remained members resisting this change.


пн, 4 мар. 2019 г. в 09:58, Ross Gardler :

> That's right Greg. And since we are filling in gaps for people...
>
> I was originally against the pTLP concept (though I supported the
> experiments) or any of the derivatives that came from it. I think I have
> changed my position. Largely based on the fact that every single project
> I've discussed the ASF with in the last 3-5 years has had a very inaccurate
> perception of how the ASF works. I believe a large part of this is due, in
> part, to the issues being discussed in this thread.
>
> I do not understand how a foundation which prides itself in having very
> little bureaucratic red tape can be seen as having so much red tape. The
> projects I talk to just want to build software. It used to be that the ASF
> focused on running the legal and operational aspects of the foundation
> projects and developers on projects wrote code. I'm not sure that's true
> anymore.
>
> We need to fix it.
>
> I look forward to hearing how the IPMC will seek to strip down the
> bureaucracy and get back to mentoring the incoming projects on how the ASF
> is structured so they can get (relatively) quick and clear answers to their
> questions.
>
> Ross
>
> 
> From: Greg Stein 
> Sent: Sunday, March 3, 2019 10:19 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler  wrote:
>
> > If a podling is a committee in its own right then it can be empowered to
> > act on behalf of the board and this its releases can be an act of the
> > foundation.
> >
> >...
>
> > Podlings would only become full TLPs once they have demonstrated their
> > ability to do formal releases.
> >
>
> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> trusted, then why not just call it a TLP and trust it to label its releases
> appropriately? Thus, just create TLPs immediately for a "podling"
>
> [ I know Ross knows this; but for $others who may want to look at
> historical proposals, and compare/contrast to current discussion ... search
> for "pTLP" ]
>
> Cheers,
> -g
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler]

That's right Greg. And since we are filling in gaps for people...

I was originally against the pTLP concept (though I supported the experiments) 
or any of the derivatives that came from it. I think I have changed my 
position. Largely based on the fact that every single project I've discussed 
the ASF with in the last 3-5 years has had a very inaccurate perception of how 
the ASF works. I believe a large part of this is due, in part, to the issues 
being discussed in this thread.

I do not understand how a foundation which prides itself in having very little 
bureaucratic red tape can be seen as having so much red tape. The projects I 
talk to just want to build software. It used to be that the ASF focused on 
running the legal and operational aspects of the foundation projects and 
developers on projects wrote code. I'm not sure that's true anymore.

We need to fix it.

I look forward to hearing how the IPMC will seek to strip down the bureaucracy 
and get back to mentoring the incoming projects on how the ASF is structured so 
they can get (relatively) quick and clear answers to their questions.

Ross


From: Greg Stein 
Sent: Sunday, March 3, 2019 10:19 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy 
general@ subs check (was:  introduce "[DISCUSS]" threads for podling ... 
release candidates))

On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler  wrote:

> If a podling is a committee in its own right then it can be empowered to
> act on behalf of the board and this its releases can be an act of the
> foundation.
>
>...

> Podlings would only become full TLPs once they have demonstrated their
> ability to do formal releases.
>

The above pair of concepts was offered in $priorCycle as "provisional TLPs"
(pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
trusted, then why not just call it a TLP and trust it to label its releases
appropriately? Thus, just create TLPs immediately for a "podling"

[ I know Ross knows this; but for $others who may want to look at
historical proposals, and compare/contrast to current discussion ... search
for "pTLP" ]

Cheers,
-g

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler]

If a podling is a committee in its own right then it can be empowered to act on 
behalf of the board and this its releases can be an act of the foundation.

We already have a good set of practices around marking incubator projects and 
their releases.

This is dependent upon the project participants being knowledgeable about how 
to do a legally compliant release. Mentors help with this and we have a legal 
committee far better versed in answering specific questions that mentors are 
unable to address.

Podlings would only become full TLPs once they have demonstrated their ability 
to do formal releases.

Ross


From: Craig Russell 
Sent: Sunday, March 3, 2019 7:48 PM
To: Incubator
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy 
general@ subs check (was:  introduce "[DISCUSS]" threads for podling ... 
release candidates))

Hi Greg,

> On Mar 3, 2019, at 6:15 PM, Greg Stein  wrote:
>
> Acts of the Foundation require specific oversight of the IPMC. To establish
> that "act", we have the (3) +1 vote rule of IPMC members. The IPMC cannot
> delegate this power further, as each IPMC member is specifically empowered
> by the Board. So PPMC members cannot act for the Foundation since they
> haven't been empowered by the Board.
>
> Again, the above is premised on *needing* that particular empowerment. If
> podling releases are no longer required to be official, then quite a bit
> can be changed.
>
I believe that this would be a disaster. I choose this word carefully.

In your proposal, would podlings' bad releases use the official Apache 
distribution mechanisms? dist.apache.org, signatures, checksums and the mirror 
systems and KEYS and such?

If so, then we need to modify Apache policy since forever, that in order to be 
An Act Of The Foundation, a board-delegated authority (currently the IPMC) must 
vote and approve the release.

If not, then we are teaching podlings nothing about official Apache Releases.

Craig

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdodata=02%7C01%7C%7C8f0ef556c879d86908d6a055b63c%7C84df9e7fe9f640afb435%7C1%7C0%7C636872687314777901sdata=B8U4hhYvv4cCT8ccNb2OKWGPJY3e8I1XW9NmsUHyl%2FU%3Dreserved=0
 
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdodata=02%7C01%7C%7C8f0ef556c879d86908d6a055b63c%7C84df9e7fe9f640afb435%7C1%7C0%7C636872687314787906sdata=bXt1jFmZTWyRJ%2B1tPmxCAXolJRUG8VGLhg9lAk0w4Oo%3Dreserved=0>

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

Re: Tying Dockerhub into development and release management

[Ross Gardler]

These would not be official releases. One or more of your community can create 
Docker builds from apache released source. Ideally the build files will be part 
of the ASF project.

Dockerhub has GitHub integration, so all it takes is for someone in the 
community to create the account and connect it to the repo.

Get Outlook for Android


From: lewis john mcgibbney 
Sent: Sunday, February 3, 2019 10:00:39 AM
To: general@incubator.apache.org
Cc: d...@sdap.apache.org
Subject: Tying Dockerhub into development and release management

Hi general@,
Over at the SDAP podling we are currently involved in a bit of a situation
regarding the use of Dockerhub in our development and release management.
The primary mechanism for the deployment of SDAP’s NEXUS component is
Docker. It is therefore necessary for us to have available Docker images
which can be consumed by people trying to consume and deploy the SDAP
software.
The issue we have run into however is that the availability of Docker
images in Dockerhub appears to be in violation of Apache release policy. Is
this true for all images e.g. tagged and version controlled, hosted within
Dockerhub or is it acceptable for us to publish version controlled images
in Dockerhub?
Can anyone share experiences facilitating the use of Dockerhub throughout
development cycles and for staging release candidates which include Docker
artifacts?
Thank you
--
https://eur02.safelinks.protection.outlook.com/?url=http:%2F%2Fhome.apache.org%2F~lewismc%2Fdata=02%7C01%7C%7C6d9017f7dbc04dc1824c08d68a018b3a%7C84df9e7fe9f640afb435%7C1%7C0%7C636848136560161169sdata=d52cOLjekmHhjncZcdI8pMnKhlXmcdxuIOaSmBFf%2F%2Bk%3Dreserved=0
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.apache.org%2Fkeys%2Fcommitter%2Flewismcdata=02%7C01%7C%7C6d9017f7dbc04dc1824c08d68a018b3a%7C84df9e7fe9f640afb435%7C1%7C0%7C636848136560161169sdata=t4CngAQFIONjFr078NHVXCXsyOk1dmKQucQvwdp2F8M%3Dreserved=0

Re: Meritocracy, initial contributors and (Incubator) Proposals

[Ross Gardler]

Some very general guidance - https://community.apache.org/newcommitter.html

Get Outlook for Android


From: Lars Francke 
Sent: Saturday, January 26, 2019 8:34:10 AM
To: general@incubator.apache.org
Subject: Meritocracy, initial contributors and (Incubator) Proposals

Hello everyone,

I should have thought of this before, but I didn't. I also did some
research in the mailing list archives, but the search terms are so common,
I didn't come up with anything.

Meritocracy is valued strongly at the ASF. Usually it is granted post-fact
when someone has proven her- or himself. There are lots of problems with
that too, but this is not about that.

This is related to the Training proposal on this list that I started
yesterday.

Proposals (and this especially) are a way to be granted something that you
usually have to work for (prove merit). I'm wondering what has been done in
the past in these situations? Is everyone just added to the list of
contributors/PMC members? There is no real limit to the number of people
that can be part of the initial team as far as I know.

Now, I know some of the people who have contacted me, and I am honored that
they chose to work with me/us on this project. Most people on here I have
never met though and even though I may have read some names on the mailing
list I have no way of assessing whether they are a good fit for a project.
I would usually just trust implicitly (by being on this list, contributor
to other projects etc.) and would say "the more the merrier". In this case
I happen to be the one who's written the proposal but it could have been
anyone really. Should it really be me judging who's a good fit? When do
we/I say "stop, we have enough"?

On the other hand, it would be a pity to have a PMC/initial contributors
list with inactive people and no way to "prune" it. This can be problematic
depending on bylaws (which I've been bitten by already in another project)
and for other reasons.

I'm looking for any advice and past experiences.

Cheers,
Lars

RE: New member - Help me to find out project

[ross]

Short version is all projects need your help. See 
http://community.apache.org/newcomers/ for some guidance on finding one that 
suits you.

-Original Message-
From: $uMe$h <1cool.1...@gmail.com> 
Sent: Saturday, September 22, 2018 12:11 AM
To: general@incubator.apache.org
Subject: New member - Help me to find out project

Hi all,

I am new here and would like contribute in new open source projects.

I mostly work on java technology and know bit of Python and JS.

Please help me to find out new project which requires more volunteers/attention.

Thanks and Regards,
Sumesh


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

RE: Mentor capactity of the incubator

[ross]

For my part I remain an IPMC member, while not having the time to mentor, 
because I take mentorship extremely seriously. If I'm not going to be able to 
read (or at least scan) every mail thread during the early days and be ready to 
respond quickly at key stages of the process then I'm not willing to sign up. 
What this translates to is I'll only step up when the project has personal 
interest to me.

A number of times in recent months I have "nearly" thrown my hat into the ring, 
only to step back when I see that there are already mentors on the project that 
I trust to do a good job.

Ross

-Original Message-
From: Greg Stein  
Sent: Sunday, September 16, 2018 4:29 AM
To: general@incubator.apache.org
Subject: Re: Mentor capactity of the incubator

On Sun, Sep 16, 2018 at 2:18 AM Justin Mclean 
wrote:
>...

> For IPMC members who are unable to be a mentor I’m curious to know 
> what the reasons are, I’m sure that “not having the time" is probably 
> the number one reason, but are is there any thing else stopping member 
> (in particular first time ones) from coming forward and volunteering?
>

For myself, it is because I conflate my personal time into my job time, working 
on Infra-related stuff. I've found that I cannot distinguish my ASF time 
between the two aspects, so cannot reliably provide dedicated ASF time to 
personal stuff.

I remain on the IPMC, however, because I *do* find that I can be responsive to 
Incubator-related concerns. (and I do the same for other ASF projects; 
responsive time, rather than allocated time)

Cheers,
-g


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

RE: Incubator Workshop

[ross]

Would such a course seek to teach the principles or the rules?

I ask because your original proposal says " making and voting on releases and 
voting on committers into the projects". There are no ***rules*** about having 
to vote. There are principles about how to build and recognize consensus. But, 
despite what much of the incubator documentation says, there are no formal 
rules about it.

I'm 100% for teaching people the principles of consensus building around 
releases and honoring people with committership. Even better if such a course 
gave concrete examples of how different communities apply those principles in 
different ways. However, I'm 100% against an opinionated piece that gives the 
impression that there is only one way to do things here in Apache. We already 
have way too much of that in Incubator docs.

Ross

-Original Message-
From: Justin Mclean  
Sent: Monday, September 10, 2018 3:54 PM
To: general@incubator.apache.org
Subject: Re: Incubator Workshop

Hi,

> For my part, most courseware is just an *extremely* slow form of 
> reading. I really don't need to have somebody read to me.

I tend to agree I also prefer to read something than watch a video, when I do I 
using speed it up. However different people learn in different ways. Currently 
we have a couple of ways people learn this stuff; from the website, by guidance 
by mentors, discussion on mailing lists, and possibly from conferences or 
conference recordings. I’ve just finished a qualification in adult learning and 
some of the biggest takeaways from it was people learn in differs ways but 
learn best when exposed to a a variety of ways and the effectiveness of the “do 
it fast”, “do it slow”, “let them do it” method for learning practical skills.

Thanks,
Justin


-
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: The role of a mentor

[ross]

I agree with the observations and clarifications to my post.

I should perhaps have prefaced my opinion with "If I agree to mentor I assume I 
will [read everything] for the first x months and then monitor for problems 
after that"

This is why I've not mentored a project for some time. It *is* very time 
consuming if we are to do it right, especially at the start.

Ross

-Original Message-
From: Ted Dunning <ted.dunn...@gmail.com> 
Sent: Wednesday, April 11, 2018 9:56 PM
To: general@incubator.apache.org
Subject: Re: The role of a mentor

I try to be more aware early on and then ease up later after things start 
moving smoothly.

I still watch a lot, however.



On Wed, Apr 11, 2018 at 9:47 PM, Bertrand Delacretaz < 
bdelacre...@codeconsult.ch> wrote:

> On Thu, Apr 12, 2018 at 6:07 AM, Hen <bay...@apache.org> wrote:
> > ...If you
> > think of someone you view as a mentor, they didn't spend all their 
> > time looking over your shoulder. Instead you met with them from time 
> > to time
> and
> > discussed a topic that you were looking to find clarity on...
>
> That's how I see my role as a mentor - I try to become aware of where 
> help is needed, but generally don't follow everything.
>
> For this I like the [mentors] subject line tag that some podlings use 
> to raise the mentors attention on their dev list.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

RE: The role of a mentor

[ross]

Sorry, the below should say "very occasionally (in an ideal world) they need to 
say something" (thanks for the private ping on this mistake)

-Original Message-
From: r...@gardler.org <r...@gardler.org> 
Sent: Tuesday, April 10, 2018 9:36 AM
To: 'general@incubator.apache.org' <general@incubator.apache.org>
Subject: RE: The role of a mentor

+1000

I've not been very active in the incubator for some time. I've participated in 
these "role of the mentor" conversations many times over the years. I wish I'd 
been able to make my contribution as clear and accurate as Julian's 
contribution below... (applause)

A good mentor *looks* like they are doing nothing, but in fact they are reading 
every thread, watching every process being developed, thinking through every 
decision. Very occasionally (in an ideal world) they are saying nothing.

When they do choose to speak it's because something is happening that is in 
conflict with "the Apache Way". The goal is not to teach the community specific 
and rigid processes, the goal is to teach the community how to use the Apache 
Way to create communities that create software. The precise processes will 
evolve over time in a way that suits the project community.

In most cases, as the podling community matures the mentor will start to learn 
improvements to their own processes. This has certainly been true in every 
single project I've mentored over the years and why I occasionally come back 
and mentor a new project. It's a learning experience, it is NOT a teaching 
experience.

Ross

-Original Message-
From: Jim Jagielski <j...@jagunet.com>
Sent: Tuesday, April 10, 2018 7:32 AM
To: general <general@incubator.apache.org>
Subject: Re: The role of a mentor

+1

> On Apr 9, 2018, at 12:45 PM, Julian Hyde <jh...@apache.org> wrote:
> 
> Has anyone here taught someone how to fish? (Or how to make cookies, 
> or ski?)
> 
> Mostly you just stand off, watching what they do. If you see them 
> about to screw up in a big way, step in. Occasionally, offer them 
> hints for how they might do what they’re doing a little bit better.
> (Not too often, because they’ll start to resent the advice.)
> 
> It’s a time-intensive process, and most of the time the person being taught 
> thinks you’re doing nothing.
> 
> Sometimes they ask for help, and very occasionally they ask for guidance (but 
> only if you have not given them more unsolicited advice than they think they 
> need, see above).
> 
> Julian
> 
> 
>> On Apr 9, 2018, at 5:52 AM, Liang Chen <chenliang6...@gmail.com 
>> <mailto:chenliang6...@gmail.com>> wrote:
>> 
>> Hi
>> 
>> +1, agree with JB points.
>> Mentor mostly just focus on ASF policy and rules, then is ok. 
>> "Teach him how to fish", it is more important, so it would be better 
>> if mentors could provide some good example cases(role model) for them 
>> to learn, tell them how to find the solution from ASF website.
>> 
>> Regards
>> Liang
>> 
>> Jean-Baptiste Onofré wrote
>>> Hi John,
>>> 
>>> IMHO, a mentor is not necessary involved in the project 
>>> technics/codebase (it's actually a bonus).
>>> 
>>> As a mentor, I'm focusing:
>>> 1. Insure of the legal aspect of the project (ICLA/CCLA, SGA, ...) 
>>> 2. Help around infra and release preparation according to Apache 
>>> rules 3. Help to promote the project and build communities around 4.
>>> See if there's potential interaction with other podlings and 
>>> existing TLPs 5. Help to go to graduation (following the graduation
>>> checklist) 6. (optional) Help on the contribution (codebase, 
>>> website, ...)
>>> 
>>> My $0.01
>>> 
>>> Regards
>>> JB
>>> 
>>> On 04/03/2018 12:54 AM, John D. Ament wrote:
>>>> I've been following along the absent mentors discussion.  But I'm 
>>>> curious, from both an IPMC member's perspective as well as a member 
>>>> of a podling, what roles do you see for a mentor?  What are their 
>>>> responsibilities to the podling?
>>>> 
>>>> We have a few things written down, and I'm not too interested in 
>>>> rehashing the written version.  But what do podlings need from 
>>>> their mentors?
>>>> Point
>>>> you in a direction to run with?  Do the apache work for the 
>>>> podling?  Do we (the ASF) need mentors to ensure that podlings are 
>>>> operating within certain bounds?  Do we rely on mentors to be a 
>>>> read of the pulse of a podling?
>>>> 
>>>> John
>>>> 
>&g

RE: The role of a mentor

[ross]

+1000

I've not been very active in the incubator for some time. I've participated in 
these "role of the mentor" conversations many times over the years. I wish I'd 
been able to make my contribution as clear and accurate as Julian's 
contribution below... (applause)

A good mentor *looks* like they are doing nothing, but in fact they are reading 
every thread, watching every process being developed, thinking through every 
decision. Very occasionally (in an ideal world) they are saying nothing.

When they do choose to speak it's because something is happening that is in 
conflict with "the Apache Way". The goal is not to teach the community specific 
and rigid processes, the goal is to teach the community how to use the Apache 
Way to create communities that create software. The precise processes will 
evolve over time in a way that suits the project community.

In most cases, as the podling community matures the mentor will start to learn 
improvements to their own processes. This has certainly been true in every 
single project I've mentored over the years and why I occasionally come back 
and mentor a new project. It's a learning experience, it is NOT a teaching 
experience.

Ross

-Original Message-
From: Jim Jagielski <j...@jagunet.com> 
Sent: Tuesday, April 10, 2018 7:32 AM
To: general <general@incubator.apache.org>
Subject: Re: The role of a mentor

+1

> On Apr 9, 2018, at 12:45 PM, Julian Hyde <jh...@apache.org> wrote:
> 
> Has anyone here taught someone how to fish? (Or how to make cookies, 
> or ski?)
> 
> Mostly you just stand off, watching what they do. If you see them 
> about to screw up in a big way, step in. Occasionally, offer them 
> hints for how they might do what they’re doing a little bit better. 
> (Not too often, because they’ll start to resent the advice.)
> 
> It’s a time-intensive process, and most of the time the person being taught 
> thinks you’re doing nothing.
> 
> Sometimes they ask for help, and very occasionally they ask for guidance (but 
> only if you have not given them more unsolicited advice than they think they 
> need, see above).
> 
> Julian
> 
> 
>> On Apr 9, 2018, at 5:52 AM, Liang Chen <chenliang6...@gmail.com 
>> <mailto:chenliang6...@gmail.com>> wrote:
>> 
>> Hi
>> 
>> +1, agree with JB points.
>> Mentor mostly just focus on ASF policy and rules, then is ok. 
>> "Teach him how to fish", it is more important, so it would be better 
>> if mentors could provide some good example cases(role model) for them 
>> to learn, tell them how to find the solution from ASF website.
>> 
>> Regards
>> Liang
>> 
>> Jean-Baptiste Onofré wrote
>>> Hi John,
>>> 
>>> IMHO, a mentor is not necessary involved in the project 
>>> technics/codebase (it's actually a bonus).
>>> 
>>> As a mentor, I'm focusing:
>>> 1. Insure of the legal aspect of the project (ICLA/CCLA, SGA, ...) 
>>> 2. Help around infra and release preparation according to Apache 
>>> rules 3. Help to promote the project and build communities around 4. 
>>> See if there's potential interaction with other podlings and 
>>> existing TLPs 5. Help to go to graduation (following the graduation 
>>> checklist) 6. (optional) Help on the contribution (codebase, 
>>> website, ...)
>>> 
>>> My $0.01
>>> 
>>> Regards
>>> JB
>>> 
>>> On 04/03/2018 12:54 AM, John D. Ament wrote:
>>>> I've been following along the absent mentors discussion.  But I'm 
>>>> curious, from both an IPMC member's perspective as well as a member 
>>>> of a podling, what roles do you see for a mentor?  What are their 
>>>> responsibilities to the podling?
>>>> 
>>>> We have a few things written down, and I'm not too interested in 
>>>> rehashing the written version.  But what do podlings need from 
>>>> their mentors?
>>>> Point
>>>> you in a direction to run with?  Do the apache work for the 
>>>> podling?  Do we (the ASF) need mentors to ensure that podlings are 
>>>> operating within certain bounds?  Do we rely on mentors to be a 
>>>> read of the pulse of a podling?
>>>> 
>>>> John
>>>> 
>>> 
>>> --
>>> Jean-Baptiste Onofré
>> 
>>> jbonofre@
>> 
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: 
>> 
>>> general-unsubscribe@.apach

RE: [DISCUSS] Apache Amaterasu Incubator Proposal

[Ross Gardler]

Exciting stuff, it may have already been said but the name is pretty bad. To my 
(native) English ear it sounds like "Amateur".

Ross

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Monday, March 20, 2017 11:39 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Apache Amaterasu Incubator Proposal

Hi all,

gently reminder about this thread.

I would like to start a formal vote pretty soon.

Thanks,
Regards
JB

On 03/07/2017 09:49 PM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I would like to submit a new proposal to bring Amaterasu to the Apache 
> Software Foundation incubator.
>
> The proposal is included below and available on the wiki:
>
> https://wiki.apache.org/incubator/AmaterasuProposal
>
> We are eager to get your comments and questions.
>
> Thanks !
> JB (on behalf of the Amaterasu community)
>
> = Apache Amaterasu =
>
> == Abstract ==
>
> Apache Amaterasu is a framework providing continuous deployment for 
> Big Data pipelines.
>
> It provides the following capabilities:
>
>  * '''Continuous integration''' tools to '''package pipelines and run 
> tests'''.
>  * A repository to store those packaged applications: the 
> '''applications repository'''.
>  * A repository to store the pipelines, and engine configuration (for 
> instance, location of the Spark master, etc.): per environment - the 
> '''configuration repository'''.
>  * A '''dashboard''' to monitor the pipelines.
>  * A '''DSL and integration hooks''' allowing third parties to easily 
> integrate.
>
> == Proposal ==
>
> Amaterasu is a simple and powerful framework to build and dispense pipelines.
> It aims to help data engineers and data scientists to compose, 
> configure, test, package, deploy and execute data pipelines written 
> using multiple tools, languages and frameworks. Amaterasu provides a 
> standard repo structure to package big data pipelines, a YAML based 
> Domain Specific Languages (DSL) for data engineers, data scientists 
> and operations engineers to manage complex pipelines throughout their entire 
> lifecycle (Dev, UAT, Prod, etc.).
>
> == Background ==
>
> Amaterasu is a relatively new project that was created to deal with 
> some of the issues that as Consultants, we have seen recurring at different 
> client sites.
> Mainly the need to continuously deploy complex pipelines built in 
> multiple tools and languages.
> Amaterasu started as a pet project and is currently being evaluated by 
> a couple of organizations, supported by the contributors, on a 
> personal time and voluntary bases.
>
> == Rational ==
>
> As software engineers working on big data projects we have straggled 
> for a long time to apply the same CI/CD practices that have become the 
> standard in the software industry for the last few years. While some 
> of them are possible, for example Apache Spark is easy to unit test. 
> However large scale pipelines are more complex and often use data, 
> which might be un-structured as integration point, which requires heavy 
> integration tests.
>
> To automate such tests and complex deployments, we have found the need 
> to often handcraft scripts and use a mixture tools, so we have decided 
> to finally build a tool we can apply in a general way and not on a project by 
> project basis.
>
> Another issue Amaterasu is trying to tackle is the Integrating between 
> the work of software engineers, data scientists, and sometimes 
> operations engineers. The approach Amaterasu takes to integrate 
> between those three schools of thought it to provide a simple YAML 
> based DSL that provides a simple way to integrate different pipeline 
> written in the native tools for each task (R, Spark in different languages, 
> etc.).
>
> == Initial Goals ==
>
> Our initial goals are to bring Amaterasu into the ASF, transition 
> internal engineering processes into the open, and foster a 
> collaborative development model according to the "Apache Way".
>
> In addition, we intend to continue the development of Amaterasu, add 
> new features as well as  integrate better with other frameworks, including:
>
>  * Apache Arrow
>  * Apache Hive
>  * Apache Drill
>  * Apache Beam
>  * Apache YARN
>  * Farther and more complete integration with Apache Spark
>
> Other frameworks will be evaluated after those initial goals are reached.
>
> == Current Status ==
>
> Amaterasu is preview state but provide a large set of features. We 
> plan to stabilize and head to a first production ready release during 
> the incubation process. The current license is already Apache 2.0.
>
> === Meritocracy ===
>
> We intend to radically expand the initial developer

RE: [VOTE] Apache Fineract podling graduation

[Ross Gardler]

+ 1 (binding)

Great job Fineract team.

Ross

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, March 20, 2017 8:12 AM
To: general@incubator.apache.org
Subject: Re: [VOTE] Apache Fineract podling graduation

+1 (binding)

Best of luck!

Thanks,
Roman.

On Mon, Mar 20, 2017 at 1:38 AM, Myrle Krantz <my...@apache.org> wrote:
> The discussion seems to have died down, so I'm calling the vote:  I 
> propose that we graduate Apache Fineract from the Incubator.  The full 
> text of the proposal is below.  The discuss thread can be found here:
>
>
> [
> https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c
> 52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E
> ]
>
> Thank you,
> Myrle
>
>
>
> Resolution:
>
> Establish the Apache Fineract Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests 
> of the Foundation and consistent with the Foundation's purpose to 
> establish a Project Management Committee charged with the creation and 
> maintenance of open-source software, for distribution at no charge to 
> the public, related to a data management platform that provides 
> real-time, consistent access to data-intensive applications throughout 
> widely distributed cloud architectures.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee 
> (PMC), to be known as the "Apache Fineract Project", be and hereby is 
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is 
> responsible for the creation and maintenance of software related to a 
> core banking platform that provides a reliable, robust, and affordable 
> solution for entrepreneurs, financial institutions, and service 
> providers to offer financial services to the world's underbanked and 
> unbanked.
>
> RESOLVED, that the office of "Vice President, Apache Fineract" 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 
> Fineract Project, and to have primary responsibility for management of 
> the projects within the scope of responsibility of the Apache Fineract 
> 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 Fineract 
> Project:
>
> * Vishwas Babu AJ <vishwasb...@apache.org>
> * Edward Cable <edca...@apache.org>
> * Markus Geiss <mage...@apache.org>
> * Sander van der Heijden <shey...@apache.org>
> * Ishan Khanna <ishan1...@apache.org>
> * Myrle Krantz <myrl...@apache.org>
> * Terence Monteiro <tere...@apache.org>
> * Adi Nayaran Raju <rajua...@apache.org>
> * Gaurav Saini <gsai...@apache.org>
> * Nazeer Hussain Shaik <naz...@apache.org>
> * Jim Jagielski <j...@apache.org>
> * Michael Vorburger <vor...@apache.org>
>
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz be appointed 
> to the office of Vice President, Apache Fineract, 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 Fineract 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 Fineract 
> Project; and be it further
>
> RESOLVED, that the Apache Fineract Project be and hereby is tasked 
> with the migration and rationalization of the Apache Incubator 
> Fineract podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator 
> Fineract podling encumbered upon the Apache Incubator Project are 
> hereafter discharged.

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



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

RE: [VOTE] Gobblin to enter Apache Incubator

[Ross Gardler]

+1 (binding)

Not signing up to mentor, but I will be watching and hopefully helping from the 
sidelines.

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Thursday, February 16, 2017 11:27 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Gobblin to enter Apache Incubator

+1 (binding)

Happy to be mentor on it !

Regards
JB

On 02/17/2017 06:33 AM, Olivier Lamy wrote:
> Hello Everyone,
> I would like to call a vote for accepting "Gobblin" for incubation in 
> the Apache Incubator.
> The full proposal is available below, and is also available in the wiki:
> https://wiki.apache.org/incubator/GobblinProposal
>
> Please cast your vote:
>
>   [ ] +1, bring Gobblin into Incubator
>   [ ] +0, I don't care either way,
>   [ ] -1, do not bring Gobblin into Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the 
> Incubator PMC are binding.
>
> I start with my vote:
> +1 (binding)
>
> Cheers
>

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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



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

RE: Consult License Compatible Issue

[Ross Gardler]

Less of a compatible/incompatible list, more of an Apache Policy with
respect to allowable licenses in ASF software...
http://www.apache.org/legal/resolved.html

-Original Message-
From: yukon [mailto:yu...@apache.org] 
Sent: Friday, February 10, 2017 2:21 AM
To: general@incubator.apache.org
Subject: Consult License Compatible Issue

Hi IPMC,

Is there a uncompatible license list with ASL2?

Regards,
yukon


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

Re: [DISCUSS] China Contribution.

[Ross Gardler]

gt; contributors and committers..as your pattern, there are tons of "issue" to
>>> describe like
>>> Russian Contribution, German Contributions, Canada contribution or
>>> others...
>>> that's not right way.
>>>
>>> Yes, Chinese people are not native English speakers, but they are
>>> contributing to
>>> most of the ASF projects and others foundation projects very much,
>>> involved
>>> in many
>>> discussion, development, decision and others deeply.
>>>
>>> Let's try to talk with some data, here's summary about last 31 days
>>> mailing
>>> list activity from 
>>> lists.apache.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.apache.org=02%7C01%7CRoss.Gardler%40microsoft.com%7C808042edd5b14a5b10a208d40a6fcb8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636144922670088439=1chFdFfY9la%2FbEtNjMTJsBSuOmTZCJEiZUlxAZB%2BOCk%3D=0>
>>>  [1]:
>>>
>>> Project |  Emails|   Topics|   Participants
>>> HBase |   610  |406  |   100
>>> Spark   |   412  |88   |   124
>>> Kylin |   294  |144  |   61
>>> CarbonData |   852  |250  |   116
>>> HAWQ  |   284  |109  |   57
>>> Trafodion  |   87   |20   |   25
>>>
>>> There are many Chinese people are participating in these projects, you
>>> could check
>>> each one and see how Chinese people are discussing within mailing list.
>>>
>>> It's really not easy for Chinese people, they have to find out a way to
>>> access
>>> gmail or others since there's GFW, they are not native English speakers,
>>> they have limited experiences for open source especially the Apache Way.
>>> But they are willing to contribute, willing to participate global
>>> community, and try
>>> their best to learn and follow The Apache Way. We should have the patience
>>> for
>>> those new comers.
>>>
>>> As one thing I'm doing now is try to let more people to know our journey,
>>> our experience
>>>  about how to follow the Apache Way, how we overcome such
>>> challenges...through
>>> conference, events, meetup, blog, book and so on...and also helping many
>>> potential projects
>>> who are interesting to join Apache family.
>>>
>>> I would like suggest to change this topic to something like "Help
>>> Trafodion
>>> community"
>>> which will help to focus on real issue and your concern (Does Trafodion
>>> PMC
>>> know
>>> this concern?)  I'm very happy to help...share with you many articles,
>>> session recordings and
>>> others about open source, even could try to do some face to face
>>> discussion
>>> if necessary:-)
>>>
>>>
>>> [1] 
>>> https://lists.apache.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org=02%7C01%7CRoss.Gardler%40microsoft.com%7C808042edd5b14a5b10a208d40a6fcb8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636144922670088439=yd6%2BMKDX3c9Z5vMoVegPnaezKxgat4gxauBK9Nx5jsc%3D=0>
>>>   
>>> <https://lists.apache.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org=02%7C01%7CRoss.Gardler%40microsoft.com%7C808042edd5b14a5b10a208d40a6fcb8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636144922670097660=2oNou0brTf1%2BMauWp%2B9qS7RckBdCQ11RfDMnM92sQkI%3D=0>>
>>>
>>> On Fri, Nov 11, 2016 at 3:00 AM, Gunnar Tapper 
>>> <tapper.gun...@gmail.com<mailto:tapper.gun...@gmail.com>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Using the RocketMQ proposal to start a larger discussion.
>>>>
>>>> Apache Trafodion is another project that has a lot of contribution from
>>>> China.
>>>>
>>>> One of the struggles I've seen is that the contributors aren't that
>>> active
>>>> on email. Rather, they prefer to use a forum on QQ communicating in
>>>> Chinese.
>>>>
>>>> I'm currently the release manager and I must admit that it's hard not to
>>>> see all discussions. Several of us are trying to encourage questions etc
>>>> via the email lists but users just prefer Chinese forums.
>>>>
>>>> I suspect that Apache will see more of this behavior moving forward,
>>>> especially as other proposals come in. So, I'm ho

RE: [DISCUSS] RocketMQ Incubation Proposal

[Ross Gardler]

+1

> -Original Message-
> From: Luke Han [mailto:luke...@gmail.com]
> Sent: Sunday, November 6, 2016 4:46 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] RocketMQ Incubation Proposal
> 
> > My feeling reading RocketMQ is that its done in a "this is why
> > RocketMQ is better than" approach instead of "this is why RocketMQ
> > differs from them" approach.
> 
> 
> > - How can RocketMQ work with the existing Kafka or ActiveMQ
> > communities to build cross platform clients?
> > - How can RocketMQ look to leverage Cassandra, Geode, Derby as backend
> > persistence stores?
> 
> I'm afraid such question will misleading ASF's position for new project
> especially from a new community (not native English community, but maybe
> biggest one of the world) who are new to ASF and trying their best to learn 
> and
> follow the Apache Way.
> 
> I don't think ASF community will ask every project have to use currently 
> Apache
> project's client, library or anything else. There are many project just come 
> here
> and grow to success without too much "cross".
> 
> IMO, such question should go to dev@ list if it will be accepted later. or 
> just
> send to author separately:-)
> 
> Thanks
> Luke
> 
> 
> 
> 
> Best Regards!
> -
> 
> Luke Han
> 
> On Sun, Nov 6, 2016 at 2:53 AM, John D. Ament 
> wrote:
> 
> > Hi Bruce,
> >
> > On Sat, Nov 5, 2016 at 12:21 PM Bruce Snyder 
> > wrote:
> >
> > > Hi John,
> > >
> > > Proposals for new ASF projects are offered to this list for
> > > constructive feedback. I am happy to help steer the RocketMQ
> > > proposal and project
> > using
> > > your suggestions.
> > >
> > > First, as explained previously in this discussion thread by Von
> > > Gosling, there was some company IP that was mistakenly committed to
> > > the Github repository and through a '...unlucky... scavenging
> > > activity' the history was erased, as Von put it. I interpret this to
> > > mean that someone's git-fu
> > went
> > > awry which unintentionally caused the history to be removed. Von
> > > also
> > gives
> > > further explanation of the project history in a response below.
> > > Indeed, this is an unfortunate situation (and one that I've seen
> > > before with
> > git),
> > > but should this prevent the project from coming to the ASF to
> > > improve and grow under the auspices of the ASF and The Apache Way?
> > >
> >
> > I was simply trying to reiterate for Roman's sanity of what I
> > understood happened, based on Von's email, and my understanding of it.
> > I don't particularly see any concerns with it (as you mention, it
> > happens all of the time), but you may want to consider removing
> > notions that the software was open sourced in 2012, since it sounds like it
> was more of a mistake.
> > The ASF has no requirement that code coming has to be already open
> > sourced, we expect an SGA to be filed with the software coming in.
> >
> > FWIW, I still don't have a good understanding of OMS and its
> > relationship to RocketMQ.  It may be relevant (e.g. a commercial
> > product based on the open source product) or may be completely
> > irrelevant (internal project name vs external project name).
> >
> >
> > >
> > > Second, regarding your statement: 'and its a bit surprising, since
> > > Bruce
> > is
> > > the chair of one of the competitors' -- All projects at the ASF
> > > exist together regardless of their focus and all projects needs good
> > > mentors, regardless of whether they are seen as competing or not. My
> > > interest in helping the RocketMQ project is no different than my
> > > interest in
> > continuing
> > > to be involved with the ActiveMQ project. I have nearly 15 years
> > experience
> > > at the ASF and I'm not here to play games and favor one project over
> > > another. I continue to be involved with the ASF to collaborate
> > > constructively with others on open source and to foster a community
> > > of inclusiveness where we can all continually learn and grow. The
> > > ASF is an inclusive place where even experienced projects can learn
> > > from new projects. As I've said for many years, we all come for code
> > > and stay for the people. My intent is to use my experience to help a
> > > new project and people to the ASF.
> > >
> >
> > This is more of a concern of mine around the structure and content of
> > the proposal, and how some of it potentially leads to issues for the
> > eventual website around RocketMQ.  While the ASF will not limit itself
> > to a single product for a technological/functional area, I do see it
> > as an issue that a project provides references stating why you should
> > use "it" vs another Apache project.  I interpret the current
> > "Relationships to other Apache Products" section as being just that
> > right now.  My only edit to that area was to fix the moin-moin mark up
> > in use, since it wasn't creating a valid table (just as an FYI).
> >
> > Typically when 

Re: [DISCUSS] RocketMQ Incubation Proposal

[Ross Gardler]

Some folks may remember my state of the feather session a couple of years ago 
when I called for more awareness of the ASFs role in open source beyond English 
speaking countries. This was prompted by a fact finding trip to China.

RocketMQ and the team behind it was one of the projects I talked to. We 
discussed the Apache way at length, however I have not been involved with this 
proposal.

I'm excited to see this proposal. I hope we can bring this project and welcome 
the excellent team I met in China into the foundation. We will need to work 
hard to ensure the project is a success. Like other China born projects we will 
find that there are cultural differences that we need to understand, but this 
would not be the first time we, as a foundation and as individuals, accept an 
opportunity to grow in this way. Having met some of the proposing team I am 
confident that with the right mentors the project can succeed.

Bruce, thanks for stepping up to help.

Ross

---
Twitter: @rgardler


From: Bruce Snyder <bruce.sny...@gmail.com>
Sent: Saturday, November 5, 2016 9:21:47 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] RocketMQ Incubation Proposal

Hi John,

Proposals for new ASF projects are offered to this list for constructive
feedback. I am happy to help steer the RocketMQ proposal and project using
your suggestions.

First, as explained previously in this discussion thread by Von Gosling,
there was some company IP that was mistakenly committed to the Github
repository and through a '...unlucky... scavenging activity' the history was
erased, as Von put it. I interpret this to mean that someone's git-fu went
awry which unintentionally caused the history to be removed. Von also gives
further explanation of the project history in a response below. Indeed,
this is an unfortunate situation (and one that I've seen before with git),
but should this prevent the project from coming to the ASF to improve and
grow under the auspices of the ASF and The Apache Way?

Second, regarding your statement: 'and its a bit surprising, since Bruce is
the chair of one of the competitors' -- All projects at the ASF exist
together regardless of their focus and all projects needs good mentors,
regardless of whether they are seen as competing or not. My interest in
helping the RocketMQ project is no different than my interest in continuing
to be involved with the ActiveMQ project. I have nearly 15 years experience
at the ASF and I'm not here to play games and favor one project over
another. I continue to be involved with the ASF to collaborate
constructively with others on open source and to foster a community of
inclusiveness where we can all continually learn and grow. The ASF is an
inclusive place where even experienced projects can learn from new
projects. As I've said for many years, we all come for code and stay for
the people. My intent is to use my experience to help a new project and
people to the ASF.

Third, I think the two questions you have posed are both good suggestions
for discussion and debate and might even help to improve the proposal. Even
if there are no solid answers today, I think these would also be great
ideas to debate around the code base and within the project moving forward.
I really like the idea of cross-pollination with the projects you mentioned
as well as others at the ASF. Since I have not worked on the RocketMQ code
base, I will allow Von to respond to two questions posed by John with his
thoughts:

Von, can you please provide your thoughts on the following two questions
specifically:

- How can RocketMQ work with the existing Kafka or ActiveMQ communities to
build cross platform clients?
- How can RocketMQ look to leverage Cassandra, Geode, Derby as backend
persistence stores?


Bruce

On Fri, Nov 4, 2016 at 3:26 PM, John D. Ament <john.d.am...@gmail.com>
wrote:

> On Fri, Nov 4, 2016 at 4:43 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > The proposal looks fine in general, but I'm slightly concerned about:
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Falibaba%2FRocketMQ%2Fgraphs%2Fcontributors=02%7C01%7CRoss.Gardler%40microsoft.com%7Cd12890186efe4c6e60c908d40597dcff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636139597197176036=96ixj1Js5%2BytkM0Pru7nABYfTTYimOP5se5POgOMleo%3D=0
> >
> > It seems that the model so far has been -- through huge blobs of
> > code over the wall. Given that the composition of initial committers
> > is all from Alibaba I hope their mentors will spend a lot of time
> > making sure that "commit early, commit often" mentality prevails.
> >
> > In addition to that, I can't seem to reconcile the statement:
> >"The source code was opened up in 2012."
> > with what I see on GitHub. What am I missing?
> >
>
> So I think these are the 

Permission to Edit Wiki

[Alan Ross]

Alan Ross

RE: [DISCUSS] Olympian Incubation Proposal

[Ross Gardler]

Yes, with a few binding -1's there is nothing to discuss unless Datastax wish 
to reconsider. I doubt they want to discuss that on a public list.

Ross

> -Original Message-
> From: Henry Saputra [mailto:henry.sapu...@gmail.com]
> Sent: Thursday, September 29, 2016 10:57 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Olympian Incubation Proposal
> 
> With obvious block due to Datastax response, shall I CLOSE this DISCUSS thread
> until further updates, if any?
> 
> On Thursday, September 29, 2016, P. Taylor Goetz <ptgo...@gmail.com>
> wrote:
> 
> > For the record I'd be -1 as well unless DataStax chose to support it.
> >
> > I would like to give them time to change their mind though.
> >
> > -Taylor
> >
> > > On Sep 29, 2016, at 10:37 PM, Greg Stein <gst...@gmail.com
> > <javascript:;>> wrote:
> > >
> > >> On Sep 29, 2016 19:22, "P. Taylor Goetz" <ptgo...@gmail.com
> > <javascript:;>> wrote:
> > >> ...
> > >> They can block a move to the ASF, but they can’t block a fork of
> > >> the
> > > project moving elsewhere. Strong communities will regroup and live on.
> > > DataStax' reluctance to allow it could very easily be interpreted as
> > > a rejection of the ASF governance model or the Foundation itself.
> > >
> > > Yes, the community could certainly launch their fork at GitHub or
> > > some such. DataStax provided them with that ability via the ALv2
> > > license. The ASF is not a necessary step for that community.
> > >
> > >> ...
> > >> Can we wait and see if DataStax is willing to do the right thing
> > >> before
> > > shooting down the proposal as a hostile fork?
> > >
> > > My vote remains -1. That can change, based on their choices.
> > >
> > > Cheers,
> > > -g
> >
> > -
> > 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: [DISCUSS] Olympian Incubation Proposal

[Ross Gardler]

Yep. As Greg points out this is to be considered a hostile fork. So I'm -1 as 
well.

---
Twitter: @rgardler


From: Henry Saputra 
Sent: Thursday, September 29, 2016 9:55:58 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Olympian Incubation Proposal

Thanks, it shows up as separate thread so I missed it.

On Thursday, September 29, 2016, John D. Ament 
wrote:

> On Thu, Sep 29, 2016 at 9:40 PM Henry Saputra  >
> wrote:
>
> > Which other thread are you referring to?
> >
> >
> A response was received from DataStax legal.
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2Fe4f2c1403bfb4fe75fce9bd6f3182b=01%7C01%7CRoss.Gardler%40microsoft.com%7C304c3939ae2b4bbd4bde08d3e8d4f2a7%7C72f988bf86f141af91ab2d7cd011db47%7C1=l3k%2BYi6y%2F4ISy7b3JAm0CyiYcN7a8g2BjfNDYgJHCeE%3D=0
> 9a95b9830ad9893944bac01ed9@%3Cgeneral.incubator.apache.org%3E
>
>
> > On Thursday, September 29, 2016, Greg Stein  > wrote:
> >
> > > -1 (binding)
> > >
> > > See other-thread from Jason at DataStax. This would be considered a
> > hostile
> > > fork, and as Bertrand noted, the ASF does not want to accept such.
> > >
> > > On Sep 28, 2016 21:02, "Henry Saputra"  
> > > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > Please find below a proposal for a new incubator podling, Apache
> > > Olympian,
> > > > formerly Titan.
> > > > Apache Olympian is software designed to support the processing of
> > graphs
> > > so
> > > > large that they require storage and computational capacities beyond
> > what
> > > a
> > > > single machine can provide.
> > > >
> > > > This project will be a fork of Titan graph database project (
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthinkaurelius%2Ftitan%2F=01%7C01%7CRoss.Gardler%40microsoft.com%7C304c3939ae2b4bbd4bde08d3e8d4f2a7%7C72f988bf86f141af91ab2d7cd011db47%7C1=pCtyXJBkLSTGPhUc2kCuS5WwiSgG9vU9iTSlH2UM%2BC8%3D=0)
> > > >  that already come with
> Apache
> > > > License v2.0.
> > > > The project was created by company called Aurelius and was acquired
> by
> > > > Datstax.
> > > > Coming to 2016 there has been less activity in the project as the
> > > original
> > > > authors are busy with other software development, but there is
> > > significant
> > > > interest from the community (see
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fforum%2F%23!msg%2F=01%7C01%7CRoss.Gardler%40microsoft.com%7C304c3939ae2b4bbd4bde08d3e8d4f2a7%7C72f988bf86f141af91ab2d7cd011db47%7C1=8LL7F8nj3fOLUhqAktvlb61%2F4t9uoSs4t23dfIdOkg4%3D=0
> > > > aureliusgraphs/jEN_7QwVXZ4/mz3gik-FAgAJ)
> > > >
> > > > The community have tried to reaching out to Datastax to donate the
> > > > copyright and trademark of project to ASF but it was not approved.
> > > > Because of that, the community has decided to go to ASF with
> different
> > > > name: Apache Olympian.
> > > >
> > > > The wiki proposal page is located at this URL:
> > > >
> > > >   
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.apache.org%2Fincubator%2FOlympianProposal=01%7C01%7CRoss.Gardler%40microsoft.com%7C304c3939ae2b4bbd4bde08d3e8d4f2a7%7C72f988bf86f141af91ab2d7cd011db47%7C1=TuNyaBP3%2FfAoqDZjMLfdGm7OwUPuEstLqZv808Zx2Mk%3D=0
> > > >
> > > > I have also included the current text of that page below.
> > > >
> > > > Looking forward of comments or questions about this proposal.
> > > >
> > > >
> > > > Thanks,
> > > > Henry Saputra
> > > > On behalf of Apache Olympian community
> > > >
> > > >
> > > > = Apache Olympian Proposal ==
> > > >
> > > > == Abstract ==
> > > >
> > > > Olympian (formerly Titan) is software designed to support the
> > processing
> > > of
> > > > graphs so large that they require storage and computational
> capacities
> > > > beyond what a single machine can provide. Scaling graph data
> processing
> > > for
> > > > real time traversals and analytical queries is Olympian’s main
> benefit.
> > > >
> > > > == Proposal ==
> > > >
> > > > Olympian consists of about 75K of Java code under the Apache 2
> license
> > > > .
> > > >  It supports very large
> > > > graphs, with many concurrent transactions and operational graph
> > > processing.
> > > > Olympian graphs scale with the number of machines in the cluster.
> > > Olympian
> > > > already integrates with a number of Apache projects:
> > > >
> > > >-
> > > >
> > > >Provides native support for the popular property graph data model
> > > >exposed by Apache TinkerPop 

RE: [DISCUSS] Olympian Incubation Proposal

[Ross Gardler]

I think the simplest definition of a "hostile fork" is this:

Does the copyright owner object to the fork?
Yes - it's hostile
No - it’s not hostile

Ross

> -Original Message-
> From: Julian Hyde [mailto:jh...@apache.org]
> Sent: Thursday, September 29, 2016 3:11 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Olympian Incubation Proposal
> 
> Some clarification of what constitutes a “hostile fork” would indeed be 
> useful.
> On a few occasions I have had discussions with communities on joining Apache,
> and this often comes up. We have relied on precedent — and in particular, on-
> the-record comments by board members on this list — and it has been
> working OK.
> 
> Bertrand, can you clarify what you mean by “author”. Do you mean copyright
> holder or you mean the individuals? (In this case it is moot, as DataStax is 
> the
> copyright holder and the individuals are now mostly DataStax employees, but
> in other cases it is a material distinction.)
> 
> Julian
> 
> 
> > On Sep 29, 2016, at 11:05 AM, Bertrand Delacretaz
> <bdelacre...@apache.org> wrote:
> >
> > Hi Chris,
> >
> > On Thu, Sep 29, 2016 at 7:23 PM, Chris Mattmann <mattm...@apache.org>
> wrote:
> >> ...I have a bit of a different understanding. We only accept code
> >> contributions that want to be here
> >
> > This sounds similar to the discussions we had about Bloodhound back in
> > early 2012 - Roy had some good comments about what we should or should
> > not accept, at
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs.apa
> >
> che.org%2Froy_forks_2012=01%7C01%7CRoss.Gardler%40microsoft.com
> %7
> >
> Cfb88d21e13994e66fc3608d3e89c5a18%7C72f988bf86f141af91ab2d7cd011db
> 47%7
> >
> C1=Joz8YRomzG7DfCj9f%2FQ4ju0JqvgArpwM%2BS0hrTnsBdE%3D
> rved=0
> >
> > It's not all black and white, but IMO we do need some form of
> > agreement from the original authors about the ASF taking control of
> > their code. Or maybe a demonstration that they really don't care about
> > it anymore, which some of the info in this thread hints to.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

RE: [DISCUSS] Olympian Incubation Proposal

[Ross Gardler]

OK, if Datastax are not objecting to the move then this is not a hostile fork. 
You should have your champion get clearance from legal@ for accepting this code 
under the open source license it is published under rather than under the SGA.

Ross

> -Original Message-
> From: Ted Wilmes [mailto:twil...@gmail.com]
> Sent: Thursday, September 29, 2016 11:12 AM
> To: general@incubator.apache.org; mbruk...@google.com
> Subject: Re: [DISCUSS] Olympian Incubation Proposal
> 
> Hello Ross,
> Per another one of the proposal submitters, Misha Brukman: "Datastax is not
> against the move of Titan to ASF but has stated that they will neither support
> or block it, as long as it doesn't involve them participating or signing the
> software grant"  I've CC'ed him to get him onto this thread.
> 
> Thanks,
> Ted
> 
> On Thu, Sep 29, 2016 at 9:28 AM, Ross Gardler <ross.gard...@microsoft.com>
> wrote:
> 
> > I see the GitHub code is untouched for over a year. Are Datastax
> > objecting to the proposal or is it just that they are unwilling to
> > actively supporting it?
> >
> > Ross
> >
> > > -Original Message-
> > > From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> > > Sent: Thursday, September 29, 2016 10:23 AM
> > > To: general@incubator.apache.org
> > > Subject: Re: [DISCUSS] Olympian Incubation Proposal
> > >
> > > Hi Susan,
> > >
> > > community interest is the key part for sure. But we would like to
> > > avoid
> > any
> > > trouble about the grant agreement, etc.
> > >
> > > Just my $0.01
> > >
> > > Regards
> > > JB
> > >
> > > On 09/29/2016 03:03 PM, Susan Malaika wrote:
> > > > Hi JB
> > > > Datastax know about the incubator effort. As far as I know they
> > > > will
> > not sign
> > > the grant agreement. I was under the impression that the incubator
> > proposal
> > > can proceed after discussion if there is sufficient community interest.
> > > > Susan Malaika
> > > >
> > > > -Jean-Baptiste Onofré <j...@nanthrax.net> wrote: -
> > > > To: general@incubator.apache.org
> > > > From: Jean-Baptiste Onofré <j...@nanthrax.net>
> > > > Date: 09/29/2016 08:43AM
> > > > Subject: Re: [DISCUSS] Olympian Incubation Proposal
> > > >
> > > > Hi Henry,
> > > >
> > > > Is DataStax know and agree with the fork ?
> > > >
> > > > Else, the Software Grant Agreement won't be possible and it won't
> > > > be able to easy to head to graduation.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On 09/29/2016 06:01 AM, Henry Saputra wrote:
> > > >> Hi All,
> > > >>
> > > >> Please find below a proposal for a new incubator podling, Apache
> > > >> Olympian, formerly Titan.
> > > >> Apache Olympian is software designed to support the processing of
> > > >> graphs so large that they require storage and computational
> > > >> capacities beyond what a single machine can provide.
> > > >>
> > > >> This project will be a fork of Titan graph database project (
> > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >> gith
> > > >>
> > >
> ub.com%2Fthinkaurelius%2Ftitan%2F=01%7C01%7CRoss.Gardler%40mic
> > >
> rosoft.com%7Cbff6cec6c3514332c7ac08d3e87433d0%7C72f988bf86f141af91ab
> > >
> 2d7cd011db47%7C1=J9Ur0GJAXUuWr1pLwivOkykimmgPEoOK5kB1vDJlI
> > > JM%3D=0) that already come with Apache License v2.0.
> > > >> The project was created by company called Aurelius and was
> > > >> acquired by Datstax.
> > > >> Coming to 2016 there has been less activity in the project as the
> > > >> original authors are busy with other software development, but
> > > >> there is significant interest from the community (see
> > > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > >> grou
> > > >>
> > >
> ps.google.com%2Fforum%2F%23!msg%2F=01%7C01%7CRoss.Gardler%4
> > > 0micr
> > > >>
> > >
> osoft.com%7Cbff6cec6c3514332c7ac08d3e87433d0%7C72f988bf86f141af91ab
> > > 2d
> > > >>
> > >
> 7cd011db47%7C1=wwJsPajQfTfxZgrF5wwBX04kk4v7iJ0afZ0NDlYWQck%
> > > 3D
> > > >> eserved=0
&g

RE: [DISCUSS] Olympian Incubation Proposal

[Ross Gardler]

I see the GitHub code is untouched for over a year. Are Datastax objecting to 
the proposal or is it just that they are unwilling to actively supporting it? 

Ross

> -Original Message-
> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> Sent: Thursday, September 29, 2016 10:23 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Olympian Incubation Proposal
> 
> Hi Susan,
> 
> community interest is the key part for sure. But we would like to avoid any
> trouble about the grant agreement, etc.
> 
> Just my $0.01
> 
> Regards
> JB
> 
> On 09/29/2016 03:03 PM, Susan Malaika wrote:
> > Hi JB
> > Datastax know about the incubator effort. As far as I know they will not 
> > sign
> the grant agreement. I was under the impression that the incubator proposal
> can proceed after discussion if there is sufficient community interest.
> > Susan Malaika
> >
> > -Jean-Baptiste Onofré <j...@nanthrax.net> wrote: -
> > To: general@incubator.apache.org
> > From: Jean-Baptiste Onofré <j...@nanthrax.net>
> > Date: 09/29/2016 08:43AM
> > Subject: Re: [DISCUSS] Olympian Incubation Proposal
> >
> > Hi Henry,
> >
> > Is DataStax know and agree with the fork ?
> >
> > Else, the Software Grant Agreement won't be possible and it won't be
> > able to easy to head to graduation.
> >
> > Regards
> > JB
> >
> > On 09/29/2016 06:01 AM, Henry Saputra wrote:
> >> Hi All,
> >>
> >> Please find below a proposal for a new incubator podling, Apache
> >> Olympian, formerly Titan.
> >> Apache Olympian is software designed to support the processing of
> >> graphs so large that they require storage and computational
> >> capacities beyond what a single machine can provide.
> >>
> >> This project will be a fork of Titan graph database project (
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> >>
> ub.com%2Fthinkaurelius%2Ftitan%2F=01%7C01%7CRoss.Gardler%40mic
> rosoft.com%7Cbff6cec6c3514332c7ac08d3e87433d0%7C72f988bf86f141af91ab
> 2d7cd011db47%7C1=J9Ur0GJAXUuWr1pLwivOkykimmgPEoOK5kB1vDJlI
> JM%3D=0) that already come with Apache License v2.0.
> >> The project was created by company called Aurelius and was acquired
> >> by Datstax.
> >> Coming to 2016 there has been less activity in the project as the
> >> original authors are busy with other software development, but there
> >> is significant interest from the community (see
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgrou
> >>
> ps.google.com%2Fforum%2F%23!msg%2F=01%7C01%7CRoss.Gardler%4
> 0micr
> >>
> osoft.com%7Cbff6cec6c3514332c7ac08d3e87433d0%7C72f988bf86f141af91ab
> 2d
> >>
> 7cd011db47%7C1=wwJsPajQfTfxZgrF5wwBX04kk4v7iJ0afZ0NDlYWQck%
> 3D
> >> eserved=0
> >> aureliusgraphs/jEN_7QwVXZ4/mz3gik-FAgAJ)
> >>
> >> The community have tried to reaching out to Datastax to donate the
> >> copyright and trademark of project to ASF but it was not approved.
> >> Because of that, the community has decided to go to ASF with
> >> different
> >> name: Apache Olympian.
> >>
> >> The wiki proposal page is located at this URL:
> >>
> >>
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> >>
> .apache.org%2Fincubator%2FOlympianProposal=01%7C01%7CRoss.Gardl
> e
> >>
> r%40microsoft.com%7Cbff6cec6c3514332c7ac08d3e87433d0%7C72f988bf86f1
> 41
> >>
> af91ab2d7cd011db47%7C1=FBoFYhxDxEH25OjeRZYE2KrsrUIePZnG9Ce1
> 2R7o
> >> Ry0%3D=0
> >>
> >> I have also included the current text of that page below.
> >>
> >> Looking forward of comments or questions about this proposal.
> >>
> >>
> >> Thanks,
> >> Henry Saputra
> >> On behalf of Apache Olympian community
> >>
> >>
> >> = Apache Olympian Proposal ==
> >>
> >> == Abstract ==
> >>
> >> Olympian (formerly Titan) is software designed to support the
> >> processing of graphs so large that they require storage and
> >> computational capacities beyond what a single machine can provide.
> >> Scaling graph data processing for real time traversals and analytical 
> >> queries
> is Olympian’s main benefit.
> >>
> >> == Proposal ==
> >>
> >> Olympian consists of about 75K of Java code under the Apache 2
> >> license
> >>
> <https://na01.safelinks.protection.out

Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Ross Gardler]

I never said comparative use.
---
Twitter: @rgardler


From: Bertrand Delacretaz 
Sent: Sunday, September 25, 2016 1:47:38 PM
To: Incubator General
Subject: Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans 
Incubator Proposal)

Le 25 sept. 2016 18:50, "Geertjan Wielenga" <
geertjan.wiele...@googlemail.com> a écrit :

>... In all fairness, it's simply impossible to prove the comparative usage
of
> one development tool over another.
>
> I'm also concerned that this is a discussion point at all in this
context

So am I. The ASF exists to provide a space for our projects to exist, not
to compete against others.

Bertrand

RE: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Ross Gardler]

My last sentence below is too terse... I know NetBeans is a different project 
to AOO. I should not draw a direct comparis0on between the two projects. I hope 
we can avoid a long thread on how Net Beans is more attractive to developers 
than other end user projects. However, my more general point of user numbers 
not being a good indicator is remains.

> -Original Message-
> From: Ross Gardler
> Sent: Sunday, September 25, 2016 8:48 AM
> To: general@incubator.apache.org
> Subject: RE: Preliminary NetBeans cost findings (was: [DISCUSS] Apache
> NetBeans Incubator Proposal)
> 
> I do not sign the check, but I am responsible for the budgets of the 
> foundation.
> I'm not saying I would not consider such a request (and you could go straight
> to the board if I did). I'm saying a case needs to be made rather than a 
> simple
> request for cash (see other mail).
> 
> As for the numbers, user numbers are irrelevant. If that were the metric of
> success for an open source project then Open Office would be thriving.
> 
> Ross
> 
> > -Original Message-
> > From: Emilian Bold [mailto:emilian.b...@gmail.com]
> > Sent: Sunday, September 25, 2016 2:09 AM
> > To: general@incubator.apache.org
> > Subject: Preliminary NetBeans cost findings (was: [DISCUSS] Apache
> > NetBeans Incubator Proposal)
> >
> > Ross Gardler is the current president of the ASF so in a way he does
> > sign the check and should be worried about these things.
> >
> > Still, the number of Java developers is only growing and they need an
> > IDE and NetBeans is a major IDE with 1.5 million individual users!
> > This number is probably conservative since it excludes all the people
> > behind
> > (corporate) firewalls.
> >
> > Helping NetBeans would be for the public good and it really does help
> > the other Apache properties such as Ant, Maven, Tomcat, Groovy, etc.
> >
> > Business wise, NetBeans is a great deal for Apache. The netbeans.org
> > domain alone could pull in ads the cost of infrastructure (although
> > ASF might have a policy against ads, etc, etc)
> >
> >
> > --emi
> >
> > On Sun, Sep 25, 2016 at 11:14 AM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com
> > <javascript:_e(%7B%7D,'cvml','geertjan.wiele...@googlemail.com');>>
> wrote:
> >
> > > On Sun, Sep 25, 2016 at 1:16 AM, Ross Gardler wrote:
> > > >
> > > > Don't make the request until the IPMC can present an argument that
> > > > a move of NetBeans to the ASF will reverse the decline in interest
> > > > that NetBeans is seeing.
> > >
> > >
> > > OK, we do need to see the basis for that assertion. I think the only
> > > thing that cannot be tolerated is assertions without basis. Where is
> > > the evidence of "the decline in interest that NetBeans is seeing"?
> > > Because, speaking on behalf of the NetBeans community, we are not
> > > seeing that, at all. That evidence is not there or, if it is, we
> > > need to know
> > what it is.
> > >
> > > Gj
> > >
> > > On Sun, Sep 25, 2016 at 1:16 AM, Ross Gardler
> > > <ross.gard...@microsoft.com
> > > <javascript:_e(%7B%7D,'cvml','ross.gard...@microsoft.com');>>
> > > wrote:
> > >
> > > > The ASF need to justify spending an extra $10k per year in this
> > > > one project at the expense of that $10k going to other projects.
> > > >
> > > > Don't make the request until the IPMC can present an argument that
> > > > a move of NetBeans to the ASF will reverse the decline in interest
> > > > that NetBeans is seeing.
> > > >
> > > > It may sound trivial, but we can support three "traditional" ASF
> > > > projects for NetBeans budget. As a charity we need to think
> > > > carefully about how we spend our money. A solid argument that this
> > > > would reverse the downward trend for NetBeans will go a long way
> > > > to reassuring me (as one member,
> > > but
> > > > also as the person ultimately responsible for paying such a budget
> > > request
> > > > to the board).
> > > >
> > > > Ross
> > > >
> > > > ---
> > > > Twitter: @rgardler
> > > >
> > > > 
> > > > From: Ted Dunning <ted.dunn...@gmail.com
> > > <javascript:_e(%7B%7D,'cvml','ted.dunn...@gmail.com');>>
> > > > Sent: Saturday, Se

RE: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Ross Gardler]

I do not sign the check, but I am responsible for the budgets of the 
foundation. I'm not saying I would not consider such a request (and you could 
go straight to the board if I did). I'm saying a case needs to be made rather 
than a simple request for cash (see other mail).

As for the numbers, user numbers are irrelevant. If that were the metric of 
success for an open source project then Open Office would be thriving.

Ross

> -Original Message-
> From: Emilian Bold [mailto:emilian.b...@gmail.com]
> Sent: Sunday, September 25, 2016 2:09 AM
> To: general@incubator.apache.org
> Subject: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans
> Incubator Proposal)
> 
> Ross Gardler is the current president of the ASF so in a way he does sign the
> check and should be worried about these things.
> 
> Still, the number of Java developers is only growing and they need an IDE and
> NetBeans is a major IDE with 1.5 million individual users! This number is
> probably conservative since it excludes all the people behind
> (corporate) firewalls.
> 
> Helping NetBeans would be for the public good and it really does help the
> other Apache properties such as Ant, Maven, Tomcat, Groovy, etc.
> 
> Business wise, NetBeans is a great deal for Apache. The netbeans.org domain
> alone could pull in ads the cost of infrastructure (although ASF might have a
> policy against ads, etc, etc)
> 
> 
> --emi
> 
> On Sun, Sep 25, 2016 at 11:14 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com
> <javascript:_e(%7B%7D,'cvml','geertjan.wiele...@googlemail.com');>> wrote:
> 
> > On Sun, Sep 25, 2016 at 1:16 AM, Ross Gardler wrote:
> > >
> > > Don't make the request until the IPMC can present an argument that a
> > > move of NetBeans to the ASF will reverse the decline in interest
> > > that NetBeans is seeing.
> >
> >
> > OK, we do need to see the basis for that assertion. I think the only
> > thing that cannot be tolerated is assertions without basis. Where is
> > the evidence of "the decline in interest that NetBeans is seeing"?
> > Because, speaking on behalf of the NetBeans community, we are not
> > seeing that, at all. That evidence is not there or, if it is, we need to 
> > know
> what it is.
> >
> > Gj
> >
> > On Sun, Sep 25, 2016 at 1:16 AM, Ross Gardler
> > <ross.gard...@microsoft.com
> > <javascript:_e(%7B%7D,'cvml','ross.gard...@microsoft.com');>>
> > wrote:
> >
> > > The ASF need to justify spending an extra $10k per year in this one
> > > project at the expense of that $10k going to other projects.
> > >
> > > Don't make the request until the IPMC can present an argument that a
> > > move of NetBeans to the ASF will reverse the decline in interest
> > > that NetBeans is seeing.
> > >
> > > It may sound trivial, but we can support three "traditional" ASF
> > > projects for NetBeans budget. As a charity we need to think
> > > carefully about how we spend our money. A solid argument that this
> > > would reverse the downward trend for NetBeans will go a long way to
> > > reassuring me (as one member,
> > but
> > > also as the person ultimately responsible for paying such a budget
> > request
> > > to the board).
> > >
> > > Ross
> > >
> > > ---
> > > Twitter: @rgardler
> > >
> > > 
> > > From: Ted Dunning <ted.dunn...@gmail.com
> > <javascript:_e(%7B%7D,'cvml','ted.dunn...@gmail.com');>>
> > > Sent: Saturday, September 24, 2016 4:04:34 PM
> > > To: general@incubator.apache.org
> > <javascript:_e(%7B%7D,'cvml','general@incubator.apache.org');>
> > > Subject: Re: Preliminary NetBeans cost findings (was: [DISCUSS]
> > > Apache NetBeans Incubator Proposal)
> > >
> > > Should this request come from IPMC? Seems like it should be at least
> > > a
> > coop
> > > request between infra (who get the budget and the operational onus)
> > > and incubator (who cause the problem).
> > >
> > > Certainly the budget shouldn't come to the IPMC if approved.
> > >
> > > I will work with the board to determine the best form.
> > >
> > >
> > > On Sat, Sep 24, 2016 at 7:57 PM, Chris Mattmann <mattm...@apache.org
> > <javascript:_e(%7B%7D,'cvml','mattm...@apache.org');>>
> > > wrote:
> > >
> > > > Daniel this is great work. Thank you for outlining this. Wow!
> > > >
> > &

RE: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Ross Gardler]

You seem to have taken my comment as an indication that I have concerns one way 
or the other. That is not the case. What I'm saying is that to make a case for 
extra budget there needs to be solid justification that  a move to ASF will 
help the community grow. The ASF is not a magic bullet, there needs to be a 
plan coming from the incoming project. The costings here are more than we 
usually get when a new podling is considered. This is a very good start.

The data I refer to is only one data point. If you have data that contradicts 
it then provide it in your request for funds (yes this has been discussed to 
some extent across the main discuss thread, but it needs to be packaged up 
nicely for VP Infra, Prez and finally Board to consider.

My one data point is 
http://pages.zeroturnaround.com/RebelLabs-Developer-Productivity-Report-2016.html?utm_source=rebellabs_allreports_medium=rebellabs_campaign=rebellabs
 (requires sign in). That reports shows a decline from 14% in 2012 to 10% 
today. To be fair that has been steady since 2014.

The reason for my explicit request is that the foundation is currently running 
at a significant deficit. That's not a problem since we have many years of cash 
in the bank at the current deficit. However, we do need to plan for the future. 
So any new budget requests need to be fully justified. That's all I'm asking 
for. A "just because" is not sufficient. Like you and others have said there 
needs to be evidence to back up claims, simply adopting the apache way does not 
mean that NetBeans will be successful as an Apache project. If my data (limited 
to the above single data point) is inaccurate/invalid/not representative then 
you should have no problem providing evidence to the contrary when you ask for 
this budget.

One final note, back in Jan 2015 the board approved a limited experiment with 
directed sponsorship to help alleviate issues like this. Maybe this would be 
useful to the NetBeans community. See presidents report here: 
http://apache.org/foundation/records/minutes/2015/board_minutes_2015_01_21.txt

Ross

> -Original Message-
> From: m...@wadechandler.com [mailto:m...@wadechandler.com] On Behalf Of
> Wade Chandler
> Sent: Saturday, September 24, 2016 8:04 PM
> To: general@incubator.apache.org
> Subject: Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache
> NetBeans Incubator Proposal)
> 
> First, I think we need to see the data you are referring to. Anecdotally the 
> NB
> community seems to be growing. We are certainly competing with more
> projects such as VS Code and others in recent years. However, given reviews
> over the past many years of Java IDEs, NB has consistently been in the top 3.
> IntelliJ IDEA Ultimate is not an open source project by the way, so I suggest 
> any
> comparisons to it, especially in the context of an organization such as 
> Apache,
> is not relevant. Money being one thing, and everything else another, including
> OSS versus sort of OSS, I think it a fair question, but I hope not a 
> subjective and
> biased one.
> 
> Has moving to Apache ever reversed trends which you are referring? For
> instance, does Apache champion it's own model over others? Why should a
> project move to the Apache way? Us in the NB community have pushed Oracle
> to move to a more open and community focused model for years. This
> sounded like it was about to happen, and many were excited to hear Apache,
> but I don't know what goal post this is, and if realistic, and if this email 
> is to be
> viewed negatively or not.
> 
> It doesn't seem oriented towards analyzing statements of cost to be applied in
> support of other projects, or a way forward based on cost reduction or code
> sharing given the initial estimate, but instead focuses on a seemingly 
> nebulous
> decline of NetBeans which is the first news I have seen of this.
> 
> Are there ways to cut the cost estimates? GoDaddy (surely others) has some
> nice plans with unlimited storage and bandwidth, and some rewrites of some
> systems with PHP, could make some things more viable. What about cost share
> across projects with similar needs? Do no other Apache projects have plugins
> or distribution needs? Other than build servers, what can't be consolidated?
> What about monetary donations to projects or specific Apache line items? Has
> there been any such talk?
> 
> How many other OSS Java IDEs are their? Seem only 2 at the Eclipse and
> NetBeans level. Having them both exist makes the entire ecosystem healthier
> in my opinion. It would be a shame to not have one of the real open source
> Java IDEs exist as an Apache project IMO.
> 
> Thanks
> 
> Wade
> 
> On Sep 24, 2016 7:16 PM, "Ross Gardler" <ross.gard...@microsoft.com>
> wrote:
> 
> > The ASF need to justify spe

Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Ross Gardler]

The ASF need to justify spending an extra $10k per year in this one project at 
the expense of that $10k going to other projects.

Don't make the request until the IPMC can present an argument that a move of 
NetBeans to the ASF will reverse the decline in interest that NetBeans is 
seeing.

It may sound trivial, but we can support three "traditional" ASF projects for 
NetBeans budget. As a charity we need to think carefully about how we spend our 
money. A solid argument that this would reverse the downward trend for NetBeans 
will go a long way to reassuring me (as one member, but also as the person 
ultimately responsible for paying such a budget request to the board).

Ross

---
Twitter: @rgardler


From: Ted Dunning <ted.dunn...@gmail.com>
Sent: Saturday, September 24, 2016 4:04:34 PM
To: general@incubator.apache.org
Subject: Re: Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans 
Incubator Proposal)

Should this request come from IPMC? Seems like it should be at least a coop
request between infra (who get the budget and the operational onus) and
incubator (who cause the problem).

Certainly the budget shouldn't come to the IPMC if approved.

I will work with the board to determine the best form.


On Sat, Sep 24, 2016 at 7:57 PM, Chris Mattmann <mattm...@apache.org> wrote:

> Daniel this is great work. Thank you for outlining this. Wow!
>
> Chris
>
>
> On 9/24/16, 3:17 AM, "Daniel Gruno" <humbed...@apache.org> wrote:
>
> Hi folks,
>
> I've been going over the requirements for NetBeans infrastructure, it's
> ballpark costs, bandwidth, machines needed and so forth, and the cliff
> notes are as follows:
>
> - 40-50TB/month in traffic required (mostly downloads+plugins)
> - 8-13 machines/VMS are required
> - Ballpark hardware costs are between $3k and $10k per year, depending
>   on how much we can move to existing infrastructure and how close we
>   come to the original setup. The most likely figure we are working
> with
>   is $4.9k, but we should be prepared for a larger cost, just in case.
> - The maintenance will be split between infra (downloads, web site, CI,
>   new build machines) and the project (services, plugins, statistics),
>   which will undoubtedly incur additional costs in terms of infra time
>   spent on this, possibly to the tune of $10-20k in the initial phase.
>
> Certain services like the plugins hosting will rely on Legal giving the
> go-ahead for it, otherwise we'll have to find other people willing to
> host this.
>
> Other items like downloads may be offset by CDN providers offering
> their
> assistance, but we should be prepared for this not being the case from
> the beginning, thus the 40-50TB/month. Likewise, some machine costs
> may be offset by cloud providers offering services for free.
>
> Thus, I would submit to the IPMC that they consider asking the board
> for
> a budget of roughly $10k per year for the NetBeans project, as well as
> the additional time required of Infrastructure to implement this into
> the existing ASF infra. As we may be able to pool resources and utilize
> the new hardware for multiple projects, the cost may go down in the
> coming years, but this is the baseline I suggest we consider when
> approving NetBeans as a new podling.
>
> With regards,
> Daniel.
>
>
> -
> 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: Preliminary NetBeans cost findings

[Ross Gardler]

Daniel, this is excellent. Thank you. When we brought AOO in we offset some 
costs, such as bandwidth, through our arrangement with SourceForge. Can we do 
the same here? (I imagine this has already been discussed, I'm behind of those 
threads, I'm just looking for a short summary).

Shane, if the project continues at the current scale then the costs below 
continue indefinitely. If it grows/shrinks many of the costs grow/shrink with 
it (e.g. Bandwidth) others will remain constant (e.g. Build farms)



---
Twitter: @rgardler

_
From: Shane Curcuru >
Sent: Saturday, September 24, 2016 5:35 AM
Subject: Re: Preliminary NetBeans cost findings
To: >


Excellent cliff notes, and I'm really glad to see us surfacing the
issues - and costs - of incubating such a large podling.

Question: do you have a rough forecast of how long this expense/extra
infra burden will last? I.e. is this likely something we'll bear for
3-4 years and then we'll have migrated everything to a better home, or
is this a long-term cost due to how big it all is?

- Shane

Daniel Gruno wrote on 9/24/16 6:17 AM:
> Hi folks,
>
> I've been going over the requirements for NetBeans infrastructure, it's
> ballpark costs, bandwidth, machines needed and so forth, and the cliff
> notes are as follows:
>
> - 40-50TB/month in traffic required (mostly downloads+plugins)
> - 8-13 machines/VMS are required
> - Ballpark hardware costs are between $3k and $10k per year, depending
> on how much we can move to existing infrastructure and how close we
> come to the original setup. The most likely figure we are working with
> is $4.9k, but we should be prepared for a larger cost, just in case.
> - The maintenance will be split between infra (downloads, web site, CI,
> new build machines) and the project (services, plugins, statistics),
> which will undoubtedly incur additional costs in terms of infra time
> spent on this, possibly to the tune of $10-20k in the initial phase.
>
> Certain services like the plugins hosting will rely on Legal giving the
> go-ahead for it, otherwise we'll have to find other people willing to
> host this.
>
> Other items like downloads may be offset by CDN providers offering their
> assistance, but we should be prepared for this not being the case from
> the beginning, thus the 40-50TB/month. Likewise, some machine costs
> may be offset by cloud providers offering services for free.
>
> Thus, I would submit to the IPMC that they consider asking the board for
> a budget of roughly $10k per year for the NetBeans project, as well as
> the additional time required of Infrastructure to implement this into
> the existing ASF infra. As we may be able to pool resources and utilize
> the new hardware for multiple projects, the cost may go down in the
> coming years, but this is the baseline I suggest we consider when
> approving NetBeans as a new podling.
>
> With regards,
> Daniel.
>
>
> -
> 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: Incubation and GSOC

[Ross Gardler]

Really? In that case I need to apologies, as a mentor, I certainly didn't 
forward them. These new fangled email clients that know better than me what I 
need to read and what I don't.

Sent from my Windows Phone

From: Ulrich Stärk
Sent: ‎2/‎20/‎2016 4:11 AM
To: general@incubator.apache.org
Cc: 
d...@fineract.incubator.apache.org
Subject: Re: Incubation and GSOC

Hi Ed,

your mentors should have forwarded the instructions to you. If not the
short version is:

- label your issues in GSoC with 'gsoc2016'
- subscribe to ment...@community.apache.org
- wait for further instructions

Cheers,

Uli

On Thu, February 18, 2016 20:08, Ed Cable wrote:
> Greg and comdev pmc,
>
> What is the process for raising our hand to want to participate in GSOC
> under the Foundation-wide application?
>
> Do we need to get our project ideas listed somewhere prior to the GSOC org
> application deadline of Feb 19?
>
> Is there an equivalent of this page that's current for 2016?
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcommunity.apache.org%2fgsoc.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cd2b690e11d0b41cdb99d08d339eee7a8%7c72f988bf86f141af91ab2d7cd011db47%7c1=uU4xlyz%2b3B6nIMgrn1amW8oexZJzA%2fGViq1wLXI8vxU%3d
> 
>
> Cheers,
>
> Ed
>
> On Sat, Jan 16, 2016 at 6:53 PM, Greg Stein  wrote:
>
>> On Fri, Jan 15, 2016 at 7:47 AM, Markus Geiß 
>> wrote:
>> >...
>>
>> > Since we are in incubation now (Apache Fineract), I'm wondering how we
>> > will deal
>> > with this in the future. Is the IPMC supporting GSOC, is it the
>> > responsibility of the
>> > project community, or is Apache in general pro things like GSOC?
>> >
>>
>> Apache is very pro GSoC :-) ... I *started* GSoC with Chris DiBona back
>> at
>> Google in 2005. It was just the two of us running it... it was quite
>> painful. And being the ASF Chairman at the time, I made sure the ASF was
>> selected as one of the organizations :-) ... The ASF has participated
>> every
>> year since, and I don't see that changing.
>>
>> As Luciano notes, we run it Foundation-wide rather than per-project. It
>> makes it a lot easier for everybody, and we usually get lots of project
>> slots assigned to us.
>>
>> Cheers,
>> -g
>>
>
>
>
> --
> *Ed Cable*
> Director of Community Programs, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | 
> *https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org=01%7c01%7cRoss.Gardler%40microsoft.com%7cd2b690e11d0b41cdb99d08d339eee7a8%7c72f988bf86f141af91ab2d7cd011db47%7c1=f0HX85l4U9hPoT4CjYRlDXuFXnSiFAVqkPv%2fiLwITts%3d
> 
>   
> 
>



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

RE: Incubation and GSOC

[Ross Gardler]

http://community.apache.org/gsoc.html#prospective-asf-mentors-read-this

-Original Message-
From: Ed Cable [mailto:edca...@mifos.org] 
Sent: Thursday, February 18, 2016 11:09 AM
To: d...@fineract.incubator.apache.org
Cc: general@incubator.apache.org
Subject: Re: Incubation and GSOC

Greg and comdev pmc,

What is the process for raising our hand to want to participate in GSOC under 
the Foundation-wide application?

Do we need to get our project ideas listed somewhere prior to the GSOC org 
application deadline of Feb 19?

Is there an equivalent of this page that's current for 2016?

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcommunity.apache.org%2fgsoc.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cf20967ba2a144924765508d3389702de%7c72f988bf86f141af91ab2d7cd011db47%7c1=FbLvqVdfy78wSKfi06DoFM4J3Wf9cMn3jxI98bv9D0w%3d


Cheers,

Ed

On Sat, Jan 16, 2016 at 6:53 PM, Greg Stein  wrote:

> On Fri, Jan 15, 2016 at 7:47 AM, Markus Geiß  wrote:
> >...
>
> > Since we are in incubation now (Apache Fineract), I'm wondering how 
> > we will deal with this in the future. Is the IPMC supporting GSOC, 
> > is it the responsibility of the project community, or is Apache in 
> > general pro things like GSOC?
> >
>
> Apache is very pro GSoC :-) ... I *started* GSoC with Chris DiBona 
> back at Google in 2005. It was just the two of us running it... it was 
> quite painful. And being the ASF Chairman at the time, I made sure the 
> ASF was selected as one of the organizations :-) ... The ASF has 
> participated every year since, and I don't see that changing.
>
> As Luciano notes, we run it Foundation-wide rather than per-project. 
> It makes it a lot easier for everybody, and we usually get lots of 
> project slots assigned to us.
>
> Cheers,
> -g
>



--
*Ed Cable*
Director of Community Programs, Mifos Initiative edca...@mifos.org | Skype: 
edcable | Mobile: +1.484.477.8649

*Collectively Creating a World of 3 Billion Maries | 
*https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org=01%7c01%7cRoss.Gardler%40microsoft.com%7cf20967ba2a144924765508d3389702de%7c72f988bf86f141af91ab2d7cd011db47%7c1=OaYoBysfMJGNQkqO0acZRheK3T0EnBxUL7Ms%2fnnTMOA%3d

  


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

RE: Request for advice on code donation

[Ross Gardler]

CCLA is optional for ASF

-Original Message-
From: Josh Elser [mailto:josh.el...@gmail.com] 
Sent: Thursday, January 14, 2016 12:34 PM
To: d...@slider.incubator.apache.org
Cc: general@incubator.apache.org
Subject: Re: Request for advice on code donation

https://github.com/apache/incubator-slider/pull/3/commits

jbnote is the unresponsive party in question. There are a modest number of 
commits and changes from him.

Alex -- that's the thing. Aside from a "I'll get you a CCLA from my employer" 2 
months ago, I haven't heard anything from this fellow.

Ted Dunning wrote:
> How big are the contributions in question?
>
>
>
> On Thu, Jan 14, 2016 at 11:37 AM, Alex Harui  wrote:
>
>> Looks like the repo was placed under the Apache License long before 
>> this individual contributed.  So, IMO, if you are convinced this 
>> individual and his employer knew his contributions were placed under 
>> the Apache License you could gamble and accept his contributions.  If 
>> you get an objection later, you can delete and re-implement the 
>> contributions.
>>
>> My 2 cents,
>> -Alex
>>
>> On 1/14/16, 10:45 AM, "Josh Elser"  wrote:
>>
>>> Hi all,
>>>
>>> (with my podling member hat on)
>>>
>>> We have a bit of a problem over in Slider with a code donation. Full 
>>> details can be found at 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fiss
>>> ues.apache.org%2fjira%2fbrowse%2fSLIDER-977=01%7c01%7cRoss.Gard
>>> ler%40microsoft.com%7c5c368269179f4c748f3c08d31d220958%7c72f988bf86f
>>> 141af91ab2d7cd011db47%7c1=wwsW0v2jmQlT8%2fszr7U6O3VcAP6uhg%2fk
>>> Li9QE%2fmVr1k%3d
>>>
>>> In short, an app-package (a modular chunk of code that Slider runs 
>>> on Apache Hadoop's YARN ) for Kafka was offered to be included in Slider.
>>> Slider would love to accept it. We've gotten IP clearance from all 
>>> but one party who contributed to it.
>>>
>>> To the best of my knowledge, this individual contributed code to 
>>> this Kafka app-package and his company could also lay claim to his 
>>> contribution. He already had an ICLA on file, but no CCLA from his 
>>> company.
>>>
>>> Two months later, multiple pings on JIRA and even a personal email, 
>>> this person seems to be AWOL. Given my understanding of the rules, 
>>> we can't proceed because we don't have the ability to prove all 
>>> potential previous ownership of this codebase has been granted to the ASF.
>>>
>>> Any advice on how we could try to move this forward?
>>>
>>> Thanks.
>>>
>>> - Josh
>>>
>>> 
>>> - 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: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

[Ross Gardler]

Sure thing, now I'm on a real email here's the link on how to make folks aware 
of willingeness to help new community members...

http://community.apache.org/guide-to-being-a-mentor.html

Ross

-Original Message-
From: William A Rowe Jr [mailto:wr...@rowe-clan.net] 
Sent: Monday, January 11, 2016 2:21 PM
To: general@incubator.apache.org
Subject: RE: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

Agreed this is in the scope of comdev, but in terms of the data collection and 
aggregation process, you have many willing test subjects aggregated on this 
list, which sure beats broadcast mails to pmcs@.
On Jan 10, 2016 7:15 PM, "Ross Gardler" <ross.gard...@microsoft.com> wrote:

> jira is exactly how I used to run GSOC, I think the process remains 
> roughly the same. The goal WA to have a list of tasks marked as 
> "mentor available". This list could bf used throughout the year, not just 
> GSOC.
>
> I built searches for this but it never really got traction. I still 
> think it's a good idea though.
>
> Assuming folks agree with this approach I guess that makes ComDev the 
> right place.
>
> Ross
>
> Sent from my Windows Phone
> 
> From: Roman Shaposhnik<mailto:ro...@shaposhnik.org>
> Sent: ‎1/‎10/‎2016 4:35 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: Re: [IPMC Projects] may be in need of^w^w^w^w^ware looking 
> for help!
>
> On Sun, Jan 10, 2016 at 4:13 PM, Tom Barber <tom.bar...@meteorite.bi>
> wrote:
> > Just to second some of that, both incubator and outside, it would be 
> > cool if the ASF had a 'jobs board' of sorts, where projects could 
> > add
> "adverts"
> > for people when they are short of specific help. Or conversely if 
> > I'm
> bored
> > and want to do something a bit different where can I find projects 
> > who
> have
> > a need for my skill set?
> >
> > I can search distinct projects, but it would be nice to have a 
> > central location.
>
> The easiest way would be to have a JIRA view looking for open tickets 
> marked in a certain way. Then projects can start using the flags and 
> get represented.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

RE: OK to distribute some GPL licensed build tools?

[Ross Gardler]

Who says its OK? Unless approved by VP Legal it's not OK. If there has been a 
documented decision to allow this then the legal policy docs need updating 
before we start updating any Incubator docs

Sent from my Windows Phone

From: Justin Mclean
Sent: ‎1/‎10/‎2016 2:26 PM
To: general@incubator.apache.org
Subject: OK to distribute some GPL licensed build tools?

Hi,

Changing subject so not to pollute the Singa VOTE thread.

So it seem the GPL with this special exception are OK to distribute. [3][4]

Looks like our documentation may need to be updated/clarified in a couple of 
places.

For instance:
- The "GNU Free For All” license is not listed as a Category A license [1]
- Special exceptions to the GPL are not allowed [2]. Except for this special 
exception that is!
- When distributing GPL software with this exception do we need to mention so 
in LICENSE? Do we also need to distribute GPL text in COPYING as indicated in 
the header text?
- Should the text under the built tools question mention GPL with this special 
exception as OK? [3]

Thanks,
Justin

1. 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2flegal%2fresolved.html%23category-a=01%7c01%7cRoss.Gardler%40microsoft.com%7cbeab44169c784bde924e08d31a0d1362%7c72f988bf86f141af91ab2d7cd011db47%7c1=aSNEqx8NmabA8UolEgFlrB8ajBnoVUlAoZz0bJzJ9uE%3d
2. 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2flegal%2fresolved.html%23category-x=01%7c01%7cRoss.Gardler%40microsoft.com%7cbeab44169c784bde924e08d31a0d1362%7c72f988bf86f141af91ab2d7cd011db47%7c1=Sot3aqmOsqydq0Q6IFOtV%2f8Az3BlNNgM910Hzo%2fCqaU%3d
3. 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2flegal%2fresolved.html%23build-tools=01%7c01%7cRoss.Gardler%40microsoft.com%7cbeab44169c784bde924e08d31a0d1362%7c72f988bf86f141af91ab2d7cd011db47%7c1=h%2bJm9oUXBy0qT7KG2O4fXi7IfdWDe5TUtgIgGKEjw2g%3d
4. 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fLEGAL-58=01%7c01%7cRoss.Gardler%40microsoft.com%7cbeab44169c784bde924e08d31a0d1362%7c72f988bf86f141af91ab2d7cd011db47%7c1=Bxkp6g%2bobdHKrFboEMBnxzSdXkvp6yLg2AHwZePJ%2b%2bg%3d



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

RE: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

[Ross Gardler]

jira is exactly how I used to run GSOC, I think the process remains roughly the 
same. The goal WA to have a list of tasks marked as "mentor available". This 
list could bf used throughout the year, not just GSOC.

I built searches for this but it never really got traction. I still think it's 
a good idea though.

Assuming folks agree with this approach I guess that makes ComDev the right 
place.

Ross

Sent from my Windows Phone

From: Roman Shaposhnik<mailto:ro...@shaposhnik.org>
Sent: ‎1/‎10/‎2016 4:35 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: [IPMC Projects] may be in need of^w^w^w^w^ware looking for help!

On Sun, Jan 10, 2016 at 4:13 PM, Tom Barber <tom.bar...@meteorite.bi> wrote:
> Just to second some of that, both incubator and outside, it would be cool
> if the ASF had a 'jobs board' of sorts, where projects could add "adverts"
> for people when they are short of specific help. Or conversely if I'm bored
> and want to do something a bit different where can I find projects who have
> a need for my skill set?
>
> I can search distinct projects, but it would be nice to have a central
> location.

The easiest way would be to have a JIRA view looking for open tickets
marked in a certain way. Then projects can start using the flags and
get represented.

Thanks,
Roman.

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

RE: Concerted may be in need of help

[Ross Gardler]

+1

Everyone should read the subject and reset.

If IPMC members having nothing better to offer than "give up" then please 
refrain from offering your advice to mentors asking for constructive help.

That is not to say projects should linger, but unless mentors advise it we 
should not be interfering.

Ross

Sent from my Windows Phone

From: Julian Hyde<mailto:jh...@apache.org>
Sent: ‎1/‎9/‎2016 12:37 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: Concerted may be in need of help

(Removing dev@concerted from the To: list.)

Good grief. No one is suggesting there should be "steady activity
requirement". I and other Concerted mentors just have a hunch that the
project isn't doing well, and thought it would be better to bring our
concerns to this list earlier rather than later. Let's not turn it
into a debate over policy. If anyone can think of ways to help this
project, then we'd love to hear your ideas. If you can't think of ways
to help the project, or don't think the project needs to be helped,
then don't help.

Julian

On Sat, Jan 9, 2016 at 12:21 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Sat, Jan 9, 2016 at 1:27 PM, Chris Nauroth <cnaur...@hortonworks.com>
> wrote:
>
>>
>> As a Concerted mentor, I agree with the concern about lack of activity.  I
>> think this was a difficult month for the project considering both the
>> general drop in participation and the typical drop in activity that we
>> should expect to happen around the end-of-year holidays.  The monthly
>> reporting schedule implicitly requires that an incubating project show
>> some kind of demonstrable progress month-to-month.  Still, other podlings
>> did manage to sustain activity and complete a report during this time.
>>
>> I see John has already raised concern about lack of activity in the
>> mentor/shepherd notes.  I just seconded that myself.
>>
>> Can we consider giving the PPMC a chance to reset and aim to re-establish
>> steady activity this month?
>
>
> What is the steady activity requirement that has been injected into
> incubation?
>
> There are plenty of examples of projects that have enjoyed months and some
> years of lull between bursts of activity, usually around new requirements
> and
> interests by patch submittors or committers.
>
> By this reconning, there have been a number of times measured in weeks or
> months that the httpd and tomcat projects should have been folded.  Do we
> really believe that a steady state of activity is healthy?  On the
> contrary, it
> is the bursts of new activity that lead our projects into new and
> interesting
> territory, not an n commits/mo target.
>
> That said, we don't want podlings to linger here; release early, release
> often,
> demonstrate that new contributors are recognized as committers/[p]pmc
> members, and show us [incubator] that there isn't much more mentorship
> required for the effort to proceed in the model of the ASF.  A project that
> cannot get to a point of release in some reasonable time, e.g. a year or
> two, or who takes down their shingle and announces they can't attract a
> three+ community to sustain their effort, such projects should be retired.

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

RE: Concerted may be in need of help

[Ross Gardler]

+1

Sent from my Windows Phone

From: Roman Shaposhnik
Sent: ‎1/‎8/‎2016 7:35 PM
To: general@incubator.apache.org
Cc: 
d...@concerted.incubator.apache.org;
 Atri Sharma
Subject: Re: Concerted may be in need of help

On Thu, Jan 7, 2016 at 2:23 PM, Ted Dunning  wrote:
> Atri,
>
> It looks like community building is going slowly with Concerted.  This is
> understandable as a part-time activity.
>
> Would it be simpler and better for the project to build a community outside
> Apache and bring the project back for incubation once you have done so?

But what's wrong with this community building exercise within the Apache?

I honestly don't get what this is going to accomplish if we push Concerted
out AND then get them back.

I also don't get why we're so concerned about this particular community
where we had examples of very, very slow to take off communities in
the Incubator.

Thanks,
Roman.

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

[RESULTS] RE: [VOTE] Accept Fineract into Apache Incubator

[Ross Gardler]

The vote to accept Fineract into the incubator passed (12 +1 votes with plenty 
of IPMC member votes, no other votes cast)

We’ll start the process of incubation.

Ross

From: Ross Gardler
Sent: Thursday, December 10, 2015 1:22 AM
To: general@incubator.apache.org
Subject: [VOTE] Accept Fineract into Apache Incubator

I would like to call a vote on accepting the Fineract project into the Apache 
Incubator. The proposal is pasted below and posted at 
http://wiki.apache.org/incubator/FineractProposal

The vote will run for at least 72hrs

[ ] +1 Accept Fineract into the Apache Incubator
[ ] +/-0 Fine, go ahead
[ ] -1 Do not accept Fineract because [your fully justified reason for 
objection]

Thanks,
Ross

= Fineract Proposal =

== Abstract ==

Fineract (\’fīn-,ə-ˌrakt\: A hypercube for digital financial services) is an 
open source system for core banking as a platform. Fineract provides a 
reliable, robust, and affordable solution for entrepreneurs, financial 
institutions, and service providers to offer financial services to the world’s 
2 billion under and unbanked.

== Proposal ==

The aim of this proposal is to bring the Mifos X codebase and community under 
the Apache Software Foundation (ASF) umbrella in order to help coordinate the 
development effort of the growing number of organizations which contribute to 
it, and give it the confidence of the neutral, transparent, and open source 
governance policy of the ASF.

The name Mifos X will remain the property of the Mifos Initiative (a US based 
501(c)(3)) and will be used for a specific distribution of the Fineract code. 
All development efforts of the Mifos Initiative will be transferred to the 
Fineract project.

== Background ==

Mifos X is a mature and robust platform that provides loan, savings, and 
business management functionality based on market proofed requirements. The 
project was started in 2006 at the Grameen Foundation, initially creating the 
Generation One  solutions of Mifos 1 and Mifos 2, the industry’s first open 
source and web-based MIS, to support the Joint Liability Group (JLG) lending 
methodology created by Mohammed Yunus, which gained him and the Grameen Bank 
the Nobel Peace Prize for his financial work in 2006.

In 2011 the independent Mifos Initiative, a 501(c)(3), was founded with two 
goals:
 1. Create the Generation Two solution Mifos X,  an extensible API-driven 
platform purpose built for Financial Inclusion
2. Build and govern an open source community of users, developers, and service 
providers committed to using Mifos X for Financial Inclusion.

Since then a worldwide community of users, partners, and volunteers has grown 
that utilizes, develops, and supports Mifos X. More than 40 partners from 
Africa, India, China, South-East Asia and Latin America, with over 120 
deployments and 3.5 million clients, have enhanced the platform based on 
regional requirements and national regulatories.

== Rationale ==

Financial Inclusion - providing financial services to the world’s 2 billion 
under and unbanked, enabling them to become a part of the global economy - 
requires an affordable, reliable, scalable, and robust solution.

The adoption of mobile solutions and digital financial services is increasing 
at an incredible pace and has led to an influx of new innovators, financial 
institutions, and service providers into the Financial Inclusion space and into 
the Mifos community which is growing at an accelerating rate year-over-year 
since 2012.

Our rationale for joining the ASF is that as an Apache project we can better 
manage the growth and governance of our community and provide the community the 
confidence of sustainable long-term open source management, which strengthens 
their commitment and continues the growth of our vibrant, diverse community, 
collectively innovating around a single codebase, sharing the social mission to 
eliminate poverty.

== Initial Goals ==

The initial goals of the Fineract transition under the ASF umbrella are to 
establish a new home for an already fully functioning project, and also make 
sure that the entire development community governs itself in the Apache Way.

In addition, we will ensure:
1. All dependencies are compliant with the Apache License and the ASFs 
licensing policies.
a. To become compliant a refactoring of the reporting module is necessary 
to be able to swap out the Pentaho Reporting Engine. This work will be 
undertaken during incubation.
 2. Ongoing development based on our collaboratively established 2016 roadmap, 
and bring the process into the Apache Way.
3. Creating releases per Apache guidelines.

== Current Status ==

=== Meritocracy ===

We already have attributes of meritocracy embedded in our community.
 * We have a developer email list which identifies active community members who 
then become committers .
* On the user email list new features are introduced and discussed, forming the 
product roadmap, and prioritization is based on merit and need

RE: [VOTE] Accept Fineract into Apache Incubator

[Ross Gardler]

+1

From: Ross Gardler
Sent: Thursday, December 10, 2015 1:22 AM
To: general@incubator.apache.org
Subject: [VOTE] Accept Fineract into Apache Incubator

I would like to call a vote on accepting the Fineract project into the Apache 
Incubator. The proposal is pasted below and posted at 
http://wiki.apache.org/incubator/FineractProposal

The vote will run for at least 72hrs

[ ] +1 Accept Fineract into the Apache Incubator
[ ] +/-0 Fine, go ahead
[ ] -1 Do not accept Fineract because [your fully justified reason for 
objection]

Thanks,
Ross

= Fineract Proposal =

== Abstract ==

Fineract (\’fīn-,ə-ˌrakt\: A hypercube for digital financial services) is an 
open source system for core banking as a platform. Fineract provides a 
reliable, robust, and affordable solution for entrepreneurs, financial 
institutions, and service providers to offer financial services to the world’s 
2 billion under and unbanked.

== Proposal ==

The aim of this proposal is to bring the Mifos X codebase and community under 
the Apache Software Foundation (ASF) umbrella in order to help coordinate the 
development effort of the growing number of organizations which contribute to 
it, and give it the confidence of the neutral, transparent, and open source 
governance policy of the ASF.

The name Mifos X will remain the property of the Mifos Initiative (a US based 
501(c)(3)) and will be used for a specific distribution of the Fineract code. 
All development efforts of the Mifos Initiative will be transferred to the 
Fineract project.

== Background ==

Mifos X is a mature and robust platform that provides loan, savings, and 
business management functionality based on market proofed requirements. The 
project was started in 2006 at the Grameen Foundation, initially creating the 
Generation One  solutions of Mifos 1 and Mifos 2, the industry’s first open 
source and web-based MIS, to support the Joint Liability Group (JLG) lending 
methodology created by Mohammed Yunus, which gained him and the Grameen Bank 
the Nobel Peace Prize for his financial work in 2006.

In 2011 the independent Mifos Initiative, a 501(c)(3), was founded with two 
goals:
 1. Create the Generation Two solution Mifos X,  an extensible API-driven 
platform purpose built for Financial Inclusion
2. Build and govern an open source community of users, developers, and service 
providers committed to using Mifos X for Financial Inclusion.

Since then a worldwide community of users, partners, and volunteers has grown 
that utilizes, develops, and supports Mifos X. More than 40 partners from 
Africa, India, China, South-East Asia and Latin America, with over 120 
deployments and 3.5 million clients, have enhanced the platform based on 
regional requirements and national regulatories.

== Rationale ==

Financial Inclusion - providing financial services to the world’s 2 billion 
under and unbanked, enabling them to become a part of the global economy - 
requires an affordable, reliable, scalable, and robust solution.

The adoption of mobile solutions and digital financial services is increasing 
at an incredible pace and has led to an influx of new innovators, financial 
institutions, and service providers into the Financial Inclusion space and into 
the Mifos community which is growing at an accelerating rate year-over-year 
since 2012.

Our rationale for joining the ASF is that as an Apache project we can better 
manage the growth and governance of our community and provide the community the 
confidence of sustainable long-term open source management, which strengthens 
their commitment and continues the growth of our vibrant, diverse community, 
collectively innovating around a single codebase, sharing the social mission to 
eliminate poverty.

== Initial Goals ==

The initial goals of the Fineract transition under the ASF umbrella are to 
establish a new home for an already fully functioning project, and also make 
sure that the entire development community governs itself in the Apache Way.

In addition, we will ensure:
1. All dependencies are compliant with the Apache License and the ASFs 
licensing policies.
a. To become compliant a refactoring of the reporting module is necessary 
to be able to swap out the Pentaho Reporting Engine. This work will be 
undertaken during incubation.
 2. Ongoing development based on our collaboratively established 2016 roadmap, 
and bring the process into the Apache Way.
3. Creating releases per Apache guidelines.

== Current Status ==

=== Meritocracy ===

We already have attributes of meritocracy embedded in our community.
 * We have a developer email list which identifies active community members who 
then become committers .
* On the user email list new features are introduced and discussed, forming the 
product roadmap, and prioritization is based on merit and need.
* We have successfully graduated 13 Google Summer of Code interns, many of whom 
have become long-term committers and developers to the project.

=== Community

[VOTE] Accept Fineract into Apache Incubator

[Ross Gardler]

I would like to call a vote on accepting the Fineract project into the Apache 
Incubator. The proposal is pasted below and posted at 
http://wiki.apache.org/incubator/FineractProposal

The vote will run for at least 72hrs

[ ] +1 Accept Fineract into the Apache Incubator
[ ] +/-0 Fine, go ahead
[ ] -1 Do not accept Fineract because [your fully justified reason for 
objection]

Thanks,
Ross

= Fineract Proposal =

== Abstract ==

Fineract (\’fīn-,ə-ˌrakt\: A hypercube for digital financial services) is an 
open source system for core banking as a platform. Fineract provides a 
reliable, robust, and affordable solution for entrepreneurs, financial 
institutions, and service providers to offer financial services to the world’s 
2 billion under and unbanked.

== Proposal ==

The aim of this proposal is to bring the Mifos X codebase and community under 
the Apache Software Foundation (ASF) umbrella in order to help coordinate the 
development effort of the growing number of organizations which contribute to 
it, and give it the confidence of the neutral, transparent, and open source 
governance policy of the ASF.

The name Mifos X will remain the property of the Mifos Initiative (a US based 
501(c)(3)) and will be used for a specific distribution of the Fineract code. 
All development efforts of the Mifos Initiative will be transferred to the 
Fineract project.

== Background ==

Mifos X is a mature and robust platform that provides loan, savings, and 
business management functionality based on market proofed requirements. The 
project was started in 2006 at the Grameen Foundation, initially creating the 
Generation One  solutions of Mifos 1 and Mifos 2, the industry’s first open 
source and web-based MIS, to support the Joint Liability Group (JLG) lending 
methodology created by Mohammed Yunus, which gained him and the Grameen Bank 
the Nobel Peace Prize for his financial work in 2006.

In 2011 the independent Mifos Initiative, a 501(c)(3), was founded with two 
goals:
 1. Create the Generation Two solution Mifos X,  an extensible API-driven 
platform purpose built for Financial Inclusion
2. Build and govern an open source community of users, developers, and service 
providers committed to using Mifos X for Financial Inclusion.

Since then a worldwide community of users, partners, and volunteers has grown 
that utilizes, develops, and supports Mifos X. More than 40 partners from 
Africa, India, China, South-East Asia and Latin America, with over 120 
deployments and 3.5 million clients, have enhanced the platform based on 
regional requirements and national regulatories.

== Rationale ==

Financial Inclusion - providing financial services to the world’s 2 billion 
under and unbanked, enabling them to become a part of the global economy - 
requires an affordable, reliable, scalable, and robust solution.

The adoption of mobile solutions and digital financial services is increasing 
at an incredible pace and has led to an influx of new innovators, financial 
institutions, and service providers into the Financial Inclusion space and into 
the Mifos community which is growing at an accelerating rate year-over-year 
since 2012.

Our rationale for joining the ASF is that as an Apache project we can better 
manage the growth and governance of our community and provide the community the 
confidence of sustainable long-term open source management, which strengthens 
their commitment and continues the growth of our vibrant, diverse community, 
collectively innovating around a single codebase, sharing the social mission to 
eliminate poverty.

== Initial Goals ==

The initial goals of the Fineract transition under the ASF umbrella are to 
establish a new home for an already fully functioning project, and also make 
sure that the entire development community governs itself in the Apache Way.

In addition, we will ensure:
1. All dependencies are compliant with the Apache License and the ASFs 
licensing policies.
a. To become compliant a refactoring of the reporting module is necessary 
to be able to swap out the Pentaho Reporting Engine. This work will be 
undertaken during incubation.
 2. Ongoing development based on our collaboratively established 2016 roadmap, 
and bring the process into the Apache Way.
3. Creating releases per Apache guidelines.

== Current Status ==

=== Meritocracy ===

We already have attributes of meritocracy embedded in our community.
 * We have a developer email list which identifies active community members who 
then become committers .
* On the user email list new features are introduced and discussed, forming the 
product roadmap, and prioritization is based on merit and need.
* We have successfully graduated 13 Google Summer of Code interns, many of whom 
have become long-term committers and developers to the project.

=== Community ===

There are more than a hundred developers within an active developer mailing 
list. We have a large and growing installed base of users (financial

RE: [PORPOSAL] Fineract

[Ross Gardler]

For those who didn't work on the proposal I can assure you there is no 
confusion in this incoming community over who makes the decisions.

I recommended the same model I advocate in the IPMC. The model we started with. 
Champion brings the project in, is responsible if problems arise but is nt 
active say to day. Mentor (singular) helps guide the community within the 
operational structure of the ASF. Podling community make decisions (where 
community is the incoming community plus anyone who steps up).

This is how we used to work but over time the IPMC has become a piece of 
authority and gatekeeping. Multiple mentors pile on, conflicting guidance is 
given, personal versions of the Apache Way are enforced (from within the IPMC, 
nit just mentors) etc. (we have discussed this plenty, it's documented on our 
wiki).

The incoming community wanted to play by the current IPMC guidelines. As Markus 
says it was a decision of the incoming community and I respect it, even if I do 
not agree with it However, as champion, it is my job to avoid unnecessary churn 
during proposal. As champion and mentor I have no concerns over the ability of 
this project to be a healthy Apache TLP. They appear demonstrated that they 
value their community over red tape!

Sent from my Windows Phone

From: Markus Geiß
Sent: ‎12/‎6/‎2015 3:34 AM
To: general@incubator.apache.org
Subject: Re: [PORPOSAL] Fineract

Thanks for the reply ... maybe I wasn't clear enough ... I was referring to
our work prior to proposal ... we wanted our community to be in consensus
with this step b/c it also has an impact to us in a whole ... we are very
excited to join Apache and are aware of the fact that there could not be
any 'internal' side conversation bypassing the community.

Sorry if my message implied that.

Cheers

Markus
On Dec 6, 2015 12:22 PM, "Greg Stein"  wrote:

> On Sun, Dec 6, 2015 at 4:43 AM, Markus Geiß  wrote:
> >...
>
> > Joining Apache, preparing the proposal, nominating the initial
> committers,
> > and agreeing on mentors is a process governed by our community by having
> a
> > healthy discussion and finding consensus on all of these things.
> >
>
> Please be careful with a phrase such as "governed by our community", as
> that sounds somewhat isolationist and exclusive. One of the primary things
> to learn about how Apache views/wants its communities to operate, is to be
> as inclusive as possible. And that means trying to avoid the implied
> boundary defined by "our community", especially when speaking about
> governance/authority.
>
> ...
>
> I believe the goal here is reduction of authority. We *do* want our TLPs to
> be self-governing, but to do so through consensus rather than an
> application of rules and power structure. When I was Chairman of the ASF, I
> learned a very important lesson: I did not want to impose, or to use my
> position of authority, but *others* viewed me in that position regardless.
> I didn't like it, but couldn't avoid it. My personal words were sometimes
> viewed as the Chairman's words. Along similar lines, incoming podlings
> may/will view Mentors' words in light of an authority we don't wish/want
> them to have. The podling needs a few people to provide a +1 when required
> (Mentors), and it needs many people to teach it about typical Apache
> culture (Community volunteers). I'm not entirely sold on this specific
> approach, but I definitely see some sense in minimizing the potential for
> mistaken authority, especially for those new-to/learning how we work here
> at Apache. Us "old hands" get it, but that doesn't apply to noobs.
>
> Cheers,
> -g
>

RE: [PORPOSAL] Fineract

[Ross Gardler]

I'll repeat again, we want contributors who will work within the community. 
Nobody is turned  away.

Sent from my Windows Phone

From: Tim Williams<mailto:william...@gmail.com>
Sent: ‎12/‎5/‎2015 8:15 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: [PORPOSAL] Fineract

On Sat, Dec 5, 2015 at 12:41 PM, Ross Gardler
<ross.gard...@microsoft.com> wrote:
> Nobody is turned away.

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

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

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

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

> This is the opposite of "counter cultural".

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

> Contributors are what matter not mentors.

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

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

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

--tim

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

RE: [PORPOSAL] Fineract

[Ross Gardler]

Nobody is turned away. Mentors don't do the work. Contributors do. Mentors do 
not make decisions. Contributors so. Mentors have " binding votes" but that is 
just because of the structure we have in the ASF, a good mentor will only ever 
use that vote to enact the wishes of the community. This is the opposite of 
"counter cultural". Contributors are what matter not mentors.

See recent discussions in the topic of mentors and how many people. Some 
people, myself included, feel the role of mentor had changed over the years. In 
this project we want it to go back to what it was and should be. Advisors only. 
We don't want anyone in the pushing to feel mentors have authority. We want 
excellent community candidates to demonstrate how merit it's earned around 
here. That can include by giving advise from experience within the ASF, but it 
will be the podling who decide who is contributing constructively and therefore 
vote then in as committers.

Note this is nothing to do with any individual. I'll pick on Jim as we know one 
another (and in fact Jim is a supporter of the one mentor model). Jim has an 
untold amount of expertise to offer this project. I imagine, if he had the time 
to offer, he'll become a committer quickly. The same will be true for anyone 
else who contributes.

Ross

Sent from my Windows Phone

From: Tim Williams<mailto:william...@gmail.com>
Sent: ‎12/‎5/‎2015 5:08 AM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: [PORPOSAL] Fineract

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

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

Anyway, best wishes to Fineract...

Thanks,
--tim

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

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

RE: [PORPOSAL] Fineract

[Ross Gardler]

I'm replying top of thread as this is a general reply regarding mentors.

We just added Greg Stein as a third mentor. He wasn't on the originally 
submitted proposal as he was just checking on availability before confirming. 

Based on recent conversations in the IPMC I (as champion) advised the project 
stick to a single mentor who was willing to put his/her head on the block. This 
individual would take full responsibility for rapid turnaround on all items 
needing mentor feedback. However, the team had already discussed the proposal 
with a number of other people. As a result they feel that 3 mentors is 
appropriate, respecting both IPMC traditions and those already advising the 
community. Hence we have three mentors. We are not seeking more.

That said, all three mentors have a very clear understanding of their role - it 
is *just* to provide the required formality for key stages in the podlings 
lifecycle (e.g. voting) and to ensure that there is someone able to answer 
community questions. As mentors we carry no weight over those doing the actual 
work in the community. Our merit needs to be earned just like everyone elses. 

For those expressing an interest in the project please join the community as 
active participants in the code production and community building process. 
Those of you who know the three mentors know that your voice will have the 
proper weight within the community and in some cases that will be more than the 
mentors. 

Ross

-Original Message-
From: Markus Geiß [mailto:mge...@mifos.org] 
Sent: Thursday, December 3, 2015 11:32 PM
To: general@incubator.apache.org
Subject: [PORPOSAL] Fineract

Hey all,

hope this finds you well.

We, the Mifos community, want to propose our project for incubation.

Please find the proposal below.

= Fineract Proposal =

== Abstract ==

Fineract (\’fīn-,ə-ˌrakt\: A hypercube for digital financial services) is an 
open source system for core banking as a platform. Fineract provides a 
reliable, robust, and affordable solution for entrepreneurs, financial 
institutions, and service providers to offer financial services to the world’s 
2 billion under and unbanked.

== Proposal ==

The aim of this proposal is to bring the Mifos X codebase and community under 
the Apache Software Foundation (ASF) umbrella in order to help coordinate the 
development effort of the growing number of organizations which contribute to 
it, and give it the confidence of the neutral, transparent, and open source 
governance policy of the ASF.

The name Mifos X will remain the property of the Mifos Initiative (a US based 
501(c)(3)) and will be used for a specific distribution of the Fineract code. 
All development efforts of the Mifos Initiative will be transferred to the 
Fineract project.

== Background ==

Mifos X is a mature and robust platform that provides loan, savings, and 
business management functionality based on market proofed requirements. The 
project was started in 2006 at the Grameen Foundation, initially creating the 
Generation One  solutions of Mifos 1 and Mifos 2, the industry’s first open 
source and web-based MIS, to support the Joint Liability Group (JLG) lending 
methodology created by Mohammed Yunus, which gained him and the Grameen Bank 
the Nobel Peace Prize for his financial work in 2006.

In 2011 the independent Mifos Initiative, a 501(c)(3), was founded with two
goals:
 1. Create the Generation Two solution Mifos X,  an extensible API-driven 
platform purpose built for Financial Inclusion  2. Build and govern an open 
source community of users, developers, and service providers committed to using 
Mifos X for Financial Inclusion.

Since then a worldwide community of users, partners, and volunteers has grown 
that utilizes, develops, and supports Mifos X. More than 40 partners from 
Africa, India, China, South-East Asia and Latin America, with over 120 
deployments and 3.5 million clients, have enhanced the platform based on 
regional requirements and national regulatories.

== Rationale ==

Financial Inclusion - providing financial services to the world’s 2 billion 
under and unbanked, enabling them to become a part of the global economy - 
requires an affordable, reliable, scalable, and robust solution.

The adoption of mobile solutions and digital financial services is increasing 
at an incredible pace and has led to an influx of new innovators, financial 
institutions, and service providers into the Financial Inclusion space and into 
the Mifos community which is growing at an accelerating rate year-over-year 
since 2012.

Our rationale for joining the ASF is that as an Apache project we can better 
manage the growth and governance of our community and provide the community the 
confidence of sustainable long-term open source management, which strengthens 
their commitment and continues the growth of our vibrant, diverse community, 
collectively innovating around a single codebase, sharing the social mission to 
eliminate poverty

RE: [PORPOSAL] Fineract

[Ross Gardler]

 yes
 |
++---+--++
| Pivotal Software, Inc. | Spring Framework  | AL v2| yes
 |
++---+--++
| Pivotal Software, Inc. | Spring Security   | AL v2| yes
 |
++---+--++
| Sam Pullar | Mustache  | AL v2| yes
 |
++---+--++
| Square, Inc.   | retrofit  | AL v2| yes
 |
++---+--++
| Square, Inc.   | okhttp| AL v2| yes
 |
++---+--++
| Stephen Colebourne | Joda-Time | AL v2| yes
 |
++---+--++
| Szczepan Faber | Mockito   | MIT  | yes
 |
++---+--++
| Terracotta, Inc| Quartz| AL v2| yes
 |
++---+--++
| Terracotta, Inc| Ehache| AL v2| yes
 |
++---+--++
 * ^1^ = can be removed
 * ^2^ = can be replaced
 * ^3^ = need an abstraction on our side to become replaceable

== Cryptography ==

The only cryptography included by the project will be via library inclusion, 
and will be used to encrypt stored user data on mobile devices and in cloud 
storages.

== Required Resources ==

=== Mailing lists ===

 * priv...@fineract.incubator.apache.org (moderated subscriptions)
 * comm...@fineract.incubator.apache.org
 * d...@fineract.incubator.apache.org
 * u...@fineract.incubator.apache.org

=== Git Repository ===

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit-wip-us.apache.org%2frepos%2fasf%2fincubator-fineract.git=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2fc7d0295%7c72f988bf86f141af91ab2d7cd011db47%7c1=TiPMFaHgesxRpt6zU6N3FKr8C4aiSqSGrbh3vRrNg2g%3d

=== Issue Tracking ===

JIRA Project Fineract (FINERACT)

=== Other Resources ===

 * Project website 
(https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffineract.incubator.apache.org=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2fc7d0295%7c72f988bf86f141af91ab2d7cd011db47%7c1=t7bR2LGFntoPNqmtQ7Fkv71ygtULYzO44EDlmhrR5xY%3d)
 * Fineract Wiki pages 
(https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2fc7d0295%7c72f988bf86f141af91ab2d7cd011db47%7c1=qE1rD63X0mSpSddpXzDKo9qAfo%2fYgHr4RrIg1ymqBKI%3d
)

== Initial Committers ==

The following list comprises the current long term committers and does not 
contain occasional developers.

 * Vishwas Babu AJ (vishwas at confluxtechnologies dot com)
 * Edward Cable (edcable at mifos dot org)
 * Andrew Dzakpasu (andrewdzakpasu at musoni dot eu)
 * Markus Geiss (mgeiss at mifos dot org)
 * Sander van der Heijden (sander at musoni dot eu)
 * Ishan Khanna (ishan1604 at gmail dot com)
 * Myrle Krantz (mkrantz at mifos dot org)
 * Terence Monteiro (terence at sanjosesolutions dot in)
 * Adi Nayaran Raju (adi dot raju at confluxtechnologies dot com)
 * Gaurav Saini (gsaini at apache dot org)
 * Nazeer Hussain Shaik (nazeer dot shaik at confluxtechnologies dot com)
 * Michael Vorburger (mike at vorburger dot ch)

== Affiliations ==

 * Vishwas Babu AJ (Conflux Technologies)
 * Ed Cable (The Mifos Initiative)
 * Andrew Dzakpasu (Musoni Systems)
 * Markus Geiss (The Mifos Initiative)
 * Sander van der Heijden (Musoni Systems)
 * Myrle Krantz (The Mifos Initiative)
 * Terence Monteiro (SanJose Foundation)
 * Adi Nayaran Raju (Conflux Technologies)
 * Nazeer Hussain Shaik (Conflux Technologies)

== Sponsors ==

=== Champion ===

Ross Gardler

=== Nominated Mentors ===
 * Ross Gardler
 * Roman Shaposhnik

=== Sponsoring Entity ===
Incubator PMC

Cheers


*Markus Geiss*
Chief Architect
RADAR, The Mifos Initiative
mge...@mifos.org | Skype: 
https://na01.safelinks.protection.outlook.com/?url=mgeiss.mifos.org=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2fc7d0295%7c72f988bf86f141af91ab2d7cd011db47%7c1=76GT3XjBX5lzdFqLoD97ypGd4FoDUsnHLxxGvhj59L4%3d
 | Mobil: +49.152.295.05306 | 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2fc7d0295%7c72f988bf86f141af91ab2d7cd011db47%7c1=0VPLn2r7LtcYyjquGAtI6nWO6XriDR7iJPsLFo7GUUU%3d
  
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fmifos=01%7c01%7cRoss.Gardler%40microsoft.com%7cf43eec6e8e284b393c3408d2f

RE: [VOTE] Retire Ripple

[Ross Gardler]

+1

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Monday, November 30, 2015 8:54 PM
To: general@incubator.apache.org
Subject: [VOTE] Retire Ripple

Greetings,

The Ripple community has been discussing retirement on their dev list.

  
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs.apache.org%2fLjX=01%7c01%7cRoss.Gardler%40microsoft.com%7cba9a960e687d44eea7a408d2fa0b7e24%7c72f988bf86f141af91ab2d7cd011db47%7c1=Ce%2fwZWoVbE9sn4niwBV2eJPpg2MBb62qkg%2fNGPeKMRM%3d

It would be more clear cut if there had been a VOTE thread, but since the 
discussion took place on the podling dev list (rather than the private list or 
some other non-central channel), since traffic is low and thus the thread is 
very prominent, and since the subject line contains the word "retire", 
hopefully all potential contributors have received sufficient notice.

This is a vote of the IPMC to retire the podling.

[ ] +1 to retire Ripple from the Incubator [ ] -1 to keep Ripple in the 
Incubator

This vote will be held open for at least 72 hours.

Should this vote pass, I have volunteered to assist Ripple with retirement, as 
I have been assisting Droids, Kalumet and Corinthia.

Marvin Humphrey

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


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

RE: Ripple to be retired from the incubator?

[Ross Gardler]

Marvin I would love to accept your help in retiring the podling. I'll close out 
the trademark issue with the community in parallel.

Thank you
Ross

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Monday, November 30, 2015 5:30 PM
To: general@incubator.apache.org
Cc: d...@ripple.incubator.apache.org
Subject: Re: Ripple to be retired from the incubator?

On Mon, Nov 30, 2015 at 3:27 PM, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> Looks like there is consensus here. I'm not sure of the process as 
> I've never been through it before so copying general@incubator for guidance.
>
> General@ the Ripple Podling has consensus on retiring itself from the 
> Apache Incubator - what needs to be done?

There's a guide:


https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fincubator.apache.org%2fguides%2fretirement=01%7c01%7cRoss.Gardler%40microsoft.com%7ceceac54df6424746927008d2f9eef802%7c72f988bf86f141af91ab2d7cd011db47%7c1=Z%2biD5gyv57yHj7B8%2fZHs5oVafFPRiYS%2bPqD1B2BmPok%3d

I've been assisting various podlings with retirement lately (Droids, Kalumet, 
Corinthia), and I'd be happy to help with Ripple as well.  (I plan to rework 
the retirement guide, so have been gathering experience.)

According to the guide, the next step is that the podling "should" run a VOTE 
on the dev list.  Since there has been prominent discussion on Ripple's dev 
list with the word "retire" in the subject, though, arguably the entire 
community has been informed and the podling dev list VOTE can be skipped[1].

After that, the next steps are to run an IPMC VOTE on general@incubator and 
then follow the guide for closing down resources.  I can handle all that if you 
like -- just let me know.

The one thing that isn't covered in the guide is the trademark issue.  I see 
you're on top of that, though.

Marvin Humphrey

[1] The retirement guide drones on endlessly on this topic -- around half
of it is dedicated to defining the circumstances under which
the podling dev list VOTE can be skipped.

RE: Ripple to be retired from the incubator?

[Ross Gardler]

Actually adding general@ for guidance on the process

-Original Message-
From: Ross Gardler [mailto:ross.gard...@microsoft.com] 
Sent: Monday, November 30, 2015 3:21 PM
To: d...@ripple.incubator.apache.org
Subject: RE: Ripple to be retired from the incubator?

Looks like there is consensus here. I'm not sure of the process as I've never 
been through it before so copying general@incubator for guidance.

General@ the Ripple Podling has consensus on retiring itself from the Apache 
Incubator - what needs to be done?

Ross

-Original Message-
From: Brent Lintner [mailto:brent.lint...@gmail.com]
Sent: Monday, November 30, 2015 7:00 AM
To: d...@ripple.incubator.apache.org
Subject: Re: Ripple to be retired from the incubator?

+1 to retirement. Makes sense. :)

On Sun, Nov 22, 2015, 22:14 Ross Gardler <ross.gard...@microsoft.com> wrote:

> I've already checked the expectation with trademarks@ in anticipation 
> for this question. Normally assignment of trademarks happens upon 
> graduation and it seems, from a cursory check, that this is the case 
> for Ripple. In other words you need the permission of RIM/Blackberry 
> Ltd as the owners of the mark (I'm not sure what the legal status is there).
>
> Whoever wants to "own" the project moving forwards need to make a 
> formal request. First to tradema...@apache.org to check the ASF 
> doesn't actually own it and then to RIM/Blackberry.
>
> Ross
>
> -Original Message-
> From: Tim Barham [mailto:tim.bar...@microsoft.com]
> Sent: Sunday, November 22, 2015 4:59 PM
> To: d...@ripple.incubator.apache.org
> Subject: RE: Ripple to be retired from the incubator?
>
> +1 from me also.
>
> Also, in addition to Parashu's questions, how do we go about getting 
> approval to keep the Ripple name?
>
> -Original Message-
> From: Parashuram N [mailto:panar...@microsoft.com]
> Sent: Saturday, November 21, 2015 2:27 AM
> To: d...@ripple.incubator.apache.org
> Subject: Re: Ripple to be retired from the incubator?
>
> +1 to retiring it and moving to Github. What would be the process of
> retiring it, and what is the timeframe that we are looking at ?
>
>
>
>
> On 11/17/15, 9:03 AM, "Raymond Camden" <raymondcam...@gmail.com> wrote:
>
> >+1 for retiring and moving it to GitHub.
> >
> >On Tue, Nov 17, 2015 at 5:53 AM, Christian Grobmeier 
> ><c...@grobmeier.de>
> wrote:
> >> Hi all,
> >>
> >> from my observations over the long time I was mentoring this 
> >> project I can say it was always an up and down. People wanted to 
> >> progress, but it never happened as day jobs prevented it. I think 
> >> around the time Chrome introduced some tooling in that direction 
> >> (even when its missing advanced mobile features) interest decreased even 
> >> more.
> >>
> >> Today I see not much activity.
> >>
> >> Personally I think a project like Ripple does not have a chance to 
> >> build a vibrant community here. GitHub might be a better place, as 
> >> there are no formalities involved.
> >>
> >> I am +1 for retiring the project.
> >>
> >> I am bit sad about this, as I always hoped the ASF would become a 
> >> bit less Java centric, also bringing its benefits to other environments.
> >> Unfortunately I have not seen many successful web related projects 
> >> (ignoring Cordova a little).
> >>
> >> Cheers,
> >>
> >> Christian
> >>
> >>
> >> --
> >>   Christian Grobmeier
> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.gr
> obmeier.de=01%7c01%7cpanarasi%40microsoft.com%7c9874214c8d9745aaf
> 6ee08d2ef7114e8%7c72f988bf86f141af91ab2d7cd011db47%7c1=QnkKuyVwZ
> %2fLBX7ZPypAzLlvIwaLZOFbnCZJF9qnXQJE%3d
> >>
> >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww
> >> .t
> >> imeandbill.de=01%7c01%7cpanarasi%40microsoft.com%7c9874214c8d9
> >> 74
> >> 5aaf6ee08d2ef7114e8%7c72f988bf86f141af91ab2d7cd011db47%7c1=7k
> >> BT SXX1Lp5%2fFXs%2fuCX9%2bZlOZOEKzJolOUjcNtZtJN0%3d
> >>
> >> On Tue, Nov 17, 2015, at 00:50, Ross Gardler wrote:
> >>> Retiring it means the code is not being managed and thus there are 
> >>> no changes to it in the ASF.
> >>>
> >>> People can fork the code and take it elsewhere, but not 
> >>> necessarily using the name Ripple - approval would be required to take 
> >>> the name.
> >>> Under no circumstances would the name Apache Ripple be permitted.
> >>>
> >>> A project cannot 

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

[Ross Gardler]

Brock, I can assure you that's not Greg's style so I doubt you have anything to 
worry about.

-Original Message-
From: Brock Noland [mailto:br...@apache.org] 
Sent: Tuesday, November 24, 2015 9:54 PM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  wrote:
>
> Personally, I am saying RTC is destructive, and am willing to give 
> every podling that message.

Delivering that message by informing podlings of your experience is completely 
acceptable.  However, if anyone attempts to force a podling from RTC, which is 
common in ASF, to CTR, I'd honestly be exceedingly disgusted.  I am not here to 
dissuade projects who operate within ASF norms from entering the incubator.

-
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...)

[Ross Gardler]

The suggestion is to add it to the proposal template - that's before incubation 
starts.

-Original Message-
From: Niall Pemberton [mailto:niall.pember...@gmail.com] 
Sent: Monday, November 23, 2015 5:49 PM
To: general-incubator 
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein  wrote:

> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby  wrote:
>
> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  wrote:
> > >
> > > Nobody is forcing anything.
> > >
> > > Personally, I am saying RTC is destructive, and am willing to give
> every
> > > podling that message.
> >
> > If it is truly destructive, SHOULDN'T you/we be trying to force 
> > something?  And if not, doesn't that mean that it isn't really all 
> > that destructive?
> >
>
> I believe that I represent a minority position, so no... I'm not going 
> to suggest changes. I wish to forestall more projects falling into the 
> RTC trap, but (at the moment) don't believe that it makes sense to 
> attempt to apply mandates against RTC upon existing communities.
>
>
> >  As a Director, would you consider stop approving reports from ASF 
> > projects that operate under a RTC model?  If not, aren't you sending 
> > a mixed message?
> >
>
> I have thought about this, yes. Maybe add a question to the proposal 
> template, on what form they're thinking about (and where I could 
> debate the proposal against RTC). And maybe debate podlings who want 
> to graduate under RTC.
>

I think this is too late - if you want to debate it, then it needs to be when 
projects enter incubation. By the time they're ready to graduate then
(presumably) things are already going well and theres less impetus to change.

Niall




> But as a Director, if the community is producing releases, then I find 
> it difficult to point to RTC as a problem for that community. It is an 
> unprovable position: there is no way to state their community could be 
> better off under CTR.
>
>
> >
> > - Sam Ruby
> >
> > P.S.  To be clear: I am not a fan of RTC when applied to 
> > release.next branches.
>
>
> I'd appreciate your explanation of this, as "most" CTR communities 
> apply RTC to a branch as they prepare a release. What disturbs you 
> about this approach?
>
> Cheers,
> -g
>

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

[Ross Gardler]

Good point. I should add to my comments that even a CTR project uses RTC for 
non-committers. And that a release vote means that at least three people have 
reviewed the code from (at least) an IP standpoint, if not from a code quality 
standpoint.

In other words, +1

However, RTC projects do not use a mix and that's the point of contention here, 
some people feel it is suboptimal (I'm one, but others disagree). The 
discussion is not whether CTR also uses RTC at points, I believe that is a 
given.

Ross

-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby
Sent: Friday, November 20, 2015 7:43 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

+1 here too.

Most projects here fall somewhere in a spectrum between "do whatever you want 
in a branch" and "don't release without having others approve your work".  
Different projects put the point where CTR crosses over to RTC at different 
points.

*shrug*

- Sam Ruby

P.S.  Personally a fan of CTR, but I'm starting to appreciate our 
infrastructure team's puppet workflow where everything (even one line
changes) are done in a branch and everybody asks other person to merge the 
changes.

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d

On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <j...@jagunet.com> wrote:
> ++1
>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bdelacre...@apache.org> 
>> wrote:
>>
>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <j...@jagunet.com> wrote:
>>> ...httpd for example) uses RTC, CTR and Lazy Consensus 
>>> simultaneously and works like a dream
>>
>> Indeed - those are different tools that each have their own purpose.
>> They just need to be applied in the right places and at the right 
>> time.
>>
>> -Bertrand
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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


-
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...)

[Ross Gardler]

Todd asks "How do you know if someone else has already read the commit" - I 
don't care. Just as people writing code can make mistakes, so can people who 
review code. For this reason if *I* care about *that* commit I will review it 
in detail - regardless of RTC or CTR. 

The more people who follow that rule the more eyes there are on the commit. I 
trust my fellow community members to do the right thing.

RTC provides no added value for me personally since the amount of work for *me* 
is the same - I need to review every commit I care about.

Ross

-Original Message-
From: Todd Lipcon [mailto:t...@cloudera.com] 
Sent: Thursday, November 19, 2015 9:11 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> None of your statements below are any different between RTC or CTR. 
> The only time it makes aa difference is if no one does reviews.  My 
> feeling is that a community that insists on RTC believes that code 
> will not be reviewed unless committers are forced to do it.
>

Yep, that's my assumption. It's much more fun to write code than review it, so 
"forcing" people to do it is a good idea. The other worry is that, in a large 
community of developers, an implicit "people probably read the commits as they 
come in" doesn't scale. Should every person read every commit? Probably not. 
How do you know if someone else has already read the commit, or signed up to do 
so? What if it takes you a few days to get around to reviewing something, and 
by that point there are already a bunch more patches stacked up on top making 
it impossible to revert or difficult to modify? Who's in charge of fixing the 
bugs or issues in a post-commit review?

I'm sure it works fine for many communities (I use CTR on some internal 
infrastructure within small teams where bugs are less costly and the rate of 
development is slow). But it doesn't work for all.


>
> All I can say, is that for me personally I have found the process of 
> having to create a patch, submit a code review, wait for the review 
> and participate in it, then wait for the commit to be onerous enough 
> that I just don’t bother.


Sure, that's a big problem with some RTC workflows. Using gerrit or github PRs 
makes the flow much easier -- for a trivial or small patch, the sort that a 
"drive-by" contributor typically contributes, there probably won't be any 
review comments. So, they just push the patch for review, and they can be out 
of the loop for the rest of it. If the patch requires small revisions (eg 
addressing a typo or something) I think it's fine for the reviewer to just make 
the change themselves and commit on behalf of the original author to avoid the 
issue you've raised. Most RTC workflows permit this kind of thing in my 
experience.


> As I said, in a CTR community there are many times where branches are 
> created and the code is reviewed there before being merged because the 
> authors believe the code is significant enough to require it.


Amusingly enough, the RTC communities I'm a part of do the opposite: you can 
make a branch which operates under CTR, so long as it's reviewed sufficiently 
prior to its merge into trunk. This is great for rapid development and 
prototyping when a small number of contributors are working together on a new 
project.

-Todd
--
Todd Lipcon
Software Engineer, Cloudera

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

[Ross Gardler]

Summarizing:

In a healthy project I believe that the only significant things that change 
between CTR and RTC are:

1) speed of commit (CTR is faster)
2) quality of master, not releases (RTC catches most issues before commit, CTR 
shortly after commit)

I agree with others, nothing in the Apache Way says RTC is bad. Personally I 
believe CTR builds communities faster, but there are successful RTC projects. 
What really matters is  managing the trade off above.

Justification (mostly a repeat of what has been said already):

I don't care what the website says. If I have a personal interest in a project 
succeeding then I will do everything in my power to ensure it succeeds. I 
assume the same is true for everyone else. This means that "mandatory" reviews 
are not required because they just get done by the people who care about 
project success.

RTC does not guarantee reviews any more than CTR does, despite what a web page 
says. It merely guarantees a way period in which someone will give a patch a 
cursory glance. I'm not saying this is the normal RTC behavior, I'm merely 
saying this is all that is guaranteed. Fortunately the process doesn't change 
the way most people behave in a project, we can still trust them to do their 
reviews.

Furthermore, there seems to be an assumption that CTR means complex or 
controversial code will be committed. In my experience this is not true. People 
don't like to waste time writing code that may be rejected. What I see is 
people discussing such changes, and providing psuedo code and then real code 
for review before committing to master. It saves time to get early review.

Ross

Sent from my Windows Phone

From: Emmanuel Lécharny<mailto:elecha...@gmail.com>
Sent: ‎11/‎18/‎2015 6:25 AM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

Le 18/11/15 14:34, Stephen Connolly a écrit :
> On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>> I believe the issue here is that with CTR it is very easy to miss the 72h
>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>> most
>>> CTR projects operate under... and thus it can also be very easy to miss
>> the
>>> fact that there are reviews going on (and I am being generous here, I
>>> suspect that a lot of CTR commits are only reviewed within the 72h by a
>>> blind man on a galloping horse)
>> I'm not sure why you are correlating commit reviews and a 72h vote...
>> They are two really different things.
>
> When I last read up my understanding is that CTR operates as if there is a
> vote for each commit.

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=zFAIzqa9u1j6hu4m21erCSE9DRBOlcuEqRh5%2bRzHdZg%3d
 :

*Commit-Then-Review*<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=nuSlXYng%2bYfeOeEw7ce9NQ%2bKzgtrUXXZy6TselDnDUg%3d>
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
changes which permits developers to make changes at will, with the
possibility of being retroactively vetoed

<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23Veto=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=1gOiqahAGrQ0u4S1oquKWypws0%2bW04dOgwnWoiW%2flMM%3d>.
 C-T-R is an
application of decision making through lazy consensus

<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23LazyConsensus=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=M1ST2%2f3jF4UCOpl1kHGXCf1TetxHWK145jg9PGvRBcs%3d>.
 The
C-T-R model is useful in rapid-prototyping environments, but because
of the lack of mandatory review it may permit more bugs through in
daily practice than the R-T-C

<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ReviewThenCommit=01%7c01%7cRoss.Gardler%40microsoft.com%7ced413f018da3415cdfc108d2f0240bc9%7c72f988bf86f141af91ab2d7cd011db47%7c1=tMxwB8PqMZ6icAme1xnurv9jh7l3u2LU3CXPfaDTDsQ%3d>
alternative.

The important piece here is '...the lack of mandatory review...'



>  It's a really lazy vote though as the vote passes if
> nobody comments on the commit after 72h... And personally

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

[Ross Gardler]

I agree, mostly, with your mail Stephen, but I wonder about the reference you 
make to "the mess of every commits". Do you really see that?

If you do see it I suspect the project has a problem. In my experience reverts 
are rare. We prefer people improve what is there rather than revert what they 
don't like. It's not always possible so occasional reverts are likely, but you 
shouldn't be seeing lots of reverts.

Sent from my Windows Phone

From: Stephen Connolly
Sent: ‎11/‎18/‎2015 7:21 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On 18 November 2015 at 14:24, Emmanuel Lécharny  wrote:

> Le 18/11/15 14:34, Stephen Connolly a écrit :
> > On Wednesday 18 November 2015, Emmanuel Lécharny 
> > wrote:
> >
> >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> >>> I believe the issue here is that with CTR it is very easy to miss the
> 72h
> >>> lazy consensus voting (with an assumed +1 absence any votes cast) that
> >> most
> >>> CTR projects operate under... and thus it can also be very easy to miss
> >> the
> >>> fact that there are reviews going on (and I am being generous here, I
> >>> suspect that a lot of CTR commits are only reviewed within the 72h by a
> >>> blind man on a galloping horse)
> >> I'm not sure why you are correlating commit reviews and a 72h vote...
> >> They are two really different things.
> >
> > When I last read up my understanding is that CTR operates as if there is
> a
> > vote for each commit.
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=TL9a3HXjrIU7ntwJs8RqxDraGBtcz%2bzbjJACbgh%2f9LM%3d
>  :
>
> *Commit-Then-Review*<
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=3qCZYrBRMPK4j7qZpzlgHAmNW9L%2bGQp2QYgPjeDzm%2bI%3d>
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> changes which permits developers to make changes at will, with the
> possibility of being retroactively vetoed
> 
> .
>  C-T-R is an
> application of decision making through lazy consensus
> 
> .
>  The
> C-T-R model is useful in rapid-prototyping environments, but because
> of the lack of mandatory review it may permit more bugs through in
> daily practice than the R-T-C
> 
> 
> alternative.
>
> The important piece here is '...the lack of mandatory review...'
>
>
> From the same glossary:

Lazy consensus
> (Also called 'lazy approval'.) A decision-making policy which assumes
> general consent if no responses are posted within a defined period. For
> example, "I'm going to commit this by lazy consensus if no-one objects
> within the next three days." Also see Consensus Approval
> 
>  , Majority
> Approval 
> 
>  ,
> and the description of the voting process
> .

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

[Ross Gardler]

Interesting, Todd, can you identify which of your three arguments for CTR are 
not present in RTC.

Ross

-Original Message-
From: Todd Lipcon [mailto:t...@cloudera.com] 
Sent: Tuesday, November 17, 2015 11:23 PM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <gst...@gmail.com> wrote:

> On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <t...@apache.org> wrote:
> >...
>
> > I think it's a _plus_ that contributors and committers contribute 
> > code in the same way -- it's more of a level playing field for new 
> > people contributing to the project.
> >
>
> "level playing field"?? seriously??
>
> I find no logical or valid reasoning to drag committers down to the 
> same level as drive-by contributors.
>

I gave the logical and valid reasoning in previous posts in this thread:
1) no matter how seasoned a committer you are, you might make mistakes which 
are easily caught in code review
2) no matter how good you are at coding, your code might not make sense to a 
second pair of eyes, who can ask you to improve comments or docs
3) no matter if your code is perfect, the act of another person reading your 
code builds shared ownership over the code, thus alleviating bus-factor issues 
and improving the general feeling of a cohesive community developing a single 
project instead of a loose coalition of people with their own fiefdoms.

I believe this to be generally accepted in the software engineering community. 
I don't know practices at every company, but I know at least that most of the 
well-regarded technology companies I've met with have some form of pre-commit 
review, and certainly many highly adopted open source projects as well 
(especially in infrastructure software).

Either a high percentage of the world does this for "no logical or valid 
reason" or this is just a matter of opinion, and like I said, we can agree to 
disagree.

-Todd

RE: Apache Metrics, Not Apache Humans

[Ross Gardler]

It's a problem when "mentors" tell projects what to do. The role of a mentor is 
to explain the pros and cons of different approaches so that the community can 
make an optimal decision

The Apache Way is indeed about doing what is right for the community. Its not a 
prescriptive model. There are very few things in the Apache Way that are fixed 
(meritocracy, up due diligence etc.) everything else is flexible so it can be 
optimized for specific community profiles.

It's true that this can be confusing, but understanding the options and the 
related pros and cons is what leads to the right decision for that community.

Ross

Sent from my Windows Phone

From: Marko Rodriguez<mailto:okramma...@gmail.com>
Sent: ‎11/‎17/‎2015 5:14 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: Apache Metrics, Not Apache Humans

Hi,

I suppose the distilled intention of the proposal is to identify the answer(s) 
to the following question:

What makes a "good" open source project?

As I read on general@ and from our project's mentors, "good" is grounded in 
personal experience (i.e. anecdotes). Why not use the data you gather to 
quantify "good." This way its not a "well I believe," its more of "in this 
particular situation given these variables, there is a X% success rate." Also, 
it leads to more exploration -- "Huh, I don't think I've ever seen an Apache 
project do it like that -- hell, give it a try and lets glean the stats from 
it. If anything, we learn."

Personally, I'm all about: "Do whatever you want." (try it -- who cares as long 
as its legal). However, if there must be structure, perhaps The Apache Way is a 
local optima? Only a broad statistical landscape will tell. And only in data 
gathering and analysis will that landscape be constructed from the numerous, 
diverse social/technical experiments -- i.e. Apache projects!  Without the 
openness and computational introspection, Apache podlings will simply 
internalize the objective of "just do as expected and graduate." The problem is 
that this only engrains a particular philosophy/approach that may not be fit in 
the long run. It just seems (to me) that this "carrot-on-a-stick model" of 
podling/top-level is outdated much like our modern education system (just take 
the classes, get the grades, give the teacher an apple, and get the hell out of 
here).

Again -- just shootin' ideas. I have no bee-in-the-bonet or axe-to-grind. I've 
just become interested in how your minds tick...

Take care,
Marko.

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarkorodriguez.com=01%7c01%7cRoss.Gardler%40microsoft.com%7cb67cecadf1a1471c1f6008d2efb58e68%7c72f988bf86f141af91ab2d7cd011db47%7c1=wor4U8Yvu1ZkTLU4b5BwrCyQy6SfMxdQ018eOQJCy%2bM%3d

On Nov 17, 2015, at 3:12 PM, Pierre Smits <pierre.sm...@gmail.com> wrote:

> It is not the metrics that vote. Humans do.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f=01%7c01%7cRoss.Gardler%40microsoft.com%7cb67cecadf1a1471c1f6008d2efb58e68%7c72f988bf86f141af91ab2d7cd011db47%7c1=H4rR211mWURZkS1B1iBFsUOr58Gn1sid5symV9DLGAE%3d
>
> On Tue, Nov 17, 2015 at 10:39 PM, Marvin Humphrey <mar...@rectangular.com>
> wrote:
>
>> On Sun, Nov 15, 2015 at 10:49 PM, Bertrand Delacretaz
>> <bdelacre...@apache.org> wrote:
>>> On Sun, Nov 15, 2015 at 7:20 PM, Marko Rodriguez <okramma...@gmail.com>
>> wrote:
>>>> ...The Apache Way should be about metrics..
>>>> ...Get the human out of the loop!
>>>
>>> No.
>>>
>>> The ASF is built on the collective wisdom of its members and
>>> community. Having metrics-based projects might be an interesting
>>> experiment, but that's not the ASF.
>>
>> My read of the proposal is that reduces uncertainty for a project
>> attempting to achieve "good health" and discredits any critiques which
>> might be raised by individual humans. Gaming the system can be seen as
>> justifiable if you don't consider the critiques valid and chafe under
>> an authority whose legitimacy you question.
>>
>> Marvin Humphrey
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

RE: Apache Metrics, Not Apache Humans

[Ross Gardler]

Very strong -1 

I'm pretty sure the details of my objections will already be covered in the 
thread (not read it yet, just need to express my very clear objection to this 
proposal, I'll follow up else-thread if there is anything I need to add beyond 
my summary below).

Summary of my objection: community building is an art not a science, there is 
no "score" that can be placed upon a community.

Ross

-Original Message-
From: Marko Rodriguez [mailto:okramma...@gmail.com] 
Sent: Sunday, November 15, 2015 10:20 AM
To: general@incubator.apache.org
Subject: Apache Metrics, Not Apache Humans

Hi,

I was talking with Daniel Gruno and wrote the following ideas to him. Note that 
these are just ideas and not based on any real momentary issue or concern -- 
though a more general concern about how Apache should evolve.

Apache should NOT use a binary "podling" / "top-level" model. All projects 
should simply have a "health score" and that health score is derived from 
measurables. Because of Apache Infrastructure's centralized server model (email 
lists, version control, distributions, homepages, etc.), it  has the ability to 
gather metrics such as, for example, the distribution of pushes to the 
repository, the branch factor of the mailing list, the centrality of the 
project in the Central Maven repository dependency graph, the number of 
non-sequisters (dead-end conversations) in the email chain, the length of 
discussions in JIRA, etc. etc. Which metrics are important? Who care -- just 
make up things to glean from the wealth of information you already have access 
to. Watch...

Next, the Apache members subjectively say which projects they think are "good" 
(healthy). This can even be a global vote including everyone in the world and 
(should be) dynamic over time as projects evolve with time. Either way, lets 
say, the ranking says Apache Hadoop, Apache Solr, Apache Commons, etc. are the 
(collective subjective's) "best" Apache projects. Now, there should exist a 
multi-dimensional projection of the aforementioned gleaned statistics what will 
have Hadoop, Solr, Commons, etc. close to one another in metric-space 
(clustered). Likewise, low ranking projects should be close to one another in 
this space and far from Hadoop, Solr, Commons, etc. Find that projection and 
that is your "healthy metric space."

>From here, all Apache projects have a computed "healthy" score(s) and when 
>users go to download, lets say, Lucene, they go: "Cool. This is a healthy 
>project." (it has a HEALTH.txt file distributed with it, lets say). What that 
>means is that Lucene, at that release was in the "healthy" cluster of the 
>metric space. This model has various benefits:

1. There is no need to have philosophical arguments (not grounded in 
measurables) about what rules a project should follow (bounded by law). 
- Perhaps a project that is exclusive, but is X is still in the 
"healthy" subspace.
- Perhaps having bad documentation is a "unhealthy" even though 
Apache doesn't care about documentation.
- Perhaps too much discussion causes a project to become 
"unhealthy."
- Perhaps ... who knows? ... let the statistics do the talking.
-  Apache becomes a breeding ground for different models of 
open source (bounded by law), not just "The Apache Way." 
- And these models are measurable! Let us study the act 
of open source.
2. "Top-level" projects can fall from grace. 
- Currently, all "top-level" projects are "equal." This should 
by dynamic as the mighty do fall.
- It is possible for what are now "podlings" to be "healthy" as 
they simply are coming into Apache.
- "The student is the master."
- Hadoop 1.2.1 might be the healthiest version of Hadoop (as I 
tend to believe). "Hadoop" is not a thing eternal.
3. Less work for people.
- No more VOTEing on graduation.
- No more amorphous aesthetic arguments about "The Apache Way."
- No more long winded contradictory documentation about how 
things should be done (bounded by law). 

The Apache Way should be about metrics, not about philosophy as different paths 
lead to the same mountain top <--- See! Is that random Buddhist saying that 
everyone just "believes" even true? :) Get the human out of the loop!

Thanks for reading,
Marko.

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarkorodriguez.com=01%7c01%7cRoss.Gardler%40microsoft.com%7cdb866066721040907ba908d2ede96bfb%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2f0HPyoryrfAESYpJuUbCcdpXxbofK3OCnIIlFyn%2fRgg%3d

P.S. T

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

[Ross Gardler]

Dennis makes a good point.

Some to ago it became common to think of the diversity objective to become a 
minimum number of contributors from different orgs rather than an acceptance of 
new contributors views.

Now we require a behavior pattern likely to lead to diversity.

One is quantative (bad, as it does nit take everything into account) one is 
subjective (good, but open to abuse).

To have the good we merely need to trust the people involved. Providing 
guidelines is good. Having those guidelines become rules is bad.

Sent from my Windows Phone

From: Dennis E. Hamilton
Sent: ‎11/‎15/‎2015 10:28 AM
To: general@incubator.apache.org
Subject: RE: Concerning Sentry: A disagreement over the Apache Way and 
graduation

I think the Maturity Model, relied on as some guidelines for assessing a 
project, needs to be applied for that purpose in terms of identifying the 
striving-fors.  Is there evidence that particular areas are being strived for.  
Is there evidence of an anti-pattern.  How do these net out in the considered 
judgment of the person making that assessment, what facts are indicators, 
warning-signs, etc.

It is my understanding that this is not a pure pass/fail thing.  A graduation 
could be accompanied by a charge to develop/diminish/whatever in the activities 
of the newly-established PMC and having that accounted for.

Isn't this an always "on balance" determination, where in some cases, 
demonstration of remedy is required before graduation and other times not?  
(With some items being show-stoppers, I suppose, such as careless handling of 
IP clearance.)

 - Dennis



> -Original Message-
> From: justin.erenkra...@gmail.com [mailto:justin.erenkra...@gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: Sunday, November 15, 2015 07:14
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
>
> On Saturday, November 14, 2015, Rich Bowen  wrote:
>
> > No. I can use whatever criteria I like to justify my vote on a
> podlings
> > graduation, if it's in line with asf philosophy. This document is,
> and
> > accurately reflects the criteria I use when voting on a graduation.
> That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
> They
> > are useful guidelines but nobody is compelled to adhere to any
> particular
> > one of them.
> >
>
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
>
> There's a huge difference there.  If you are subjecting all of your
> votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  --
> justin


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

RE: [VOTE] Graduate REEF

[Ross Gardler]

+1


-Original Message-
From: Chris Douglas [mailto:cdoug...@apache.org] 
Sent: Monday, November 9, 2015 1:47 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Graduate REEF

+1 -C

On Mon, Nov 9, 2015 at 1:14 PM, Markus Weimer  wrote:
> This is the vote to decide if Apache REEF should graduate from the 
> Incubator. Please see the proposed resolution below.
>
> This proposal was discussed [0] and voted upon [1] by the REEF 
> community and has been discussed [2] on this list.
>
> This vote is open for at least 72 hours.
>
> [ ] +1 Graduate Apache REEF from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache REEF from the Incubator because ...
>
> Thanks,
>
> Markus
>
> [0]: 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs.apac
> he.org%2freefgraduationdiscussion=01%7c01%7cRoss.Gardler%40micros
> oft.com%7c2e6348917e55482e1c7a08d2e94f66ae%7c72f988bf86f141af91ab2d7cd
> 011db47%7c1=FdjxiP5MGog%2fxYQI68swmKF3JZtkZt3dHa1TW8NM5qM%3d
> [1]: 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs.apac
> he.org%2freefgraduationppmsvoteresult=01%7c01%7cRoss.Gardler%40mi
> crosoft.com%7c2e6348917e55482e1c7a08d2e94f66ae%7c72f988bf86f141af91ab2
> d7cd011db47%7c1=uZ%2bpPsxnrf9voUVLJBzyKIb56hd3qOyf0Qr0dwJ6kXQ%3d
> [2]: 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fs.apac
> he.org%2freefgraduationdiscussionongeneral=01%7c01%7cRoss.Gardler
> %40microsoft.com%7c2e6348917e55482e1c7a08d2e94f66ae%7c72f988bf86f141af
> 91ab2d7cd011db47%7c1=X%2f%2bpf6TfJkxgqAON1HZFEj7t3wsCiY7H5fyZM0V
> EeSI%3d
>
> 
> X. Establish the Apache REEF Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to application development on top of
> resource managers.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache REEF Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache REEF Project be and hereby is
> responsible for the creation and maintenance of a software
> framework for application development on top of resource
> managers; and be it further
>
> RESOLVED, that the office of "Vice President, Apache REEF"
> 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 REEF Project, and to have primary
> responsibility for management of the projects within the scope
> of responsibility of the Apache REEF 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 REEF Project Management Committee:
>
> * Markus Weimer 
> * Byung-Gon Chun 
> * Yunseong Lee 
> * Brian Cho 
> * Beysim Sezgin 
> * Yingda Chen 
> * Julia Wang 
> * Andrew Chung 
> * Youngseok Yang 
> * Gyewon Lee 
> * Taegeon Um 
> * Joo Seong Jeong 
> * Geon-Woo Kim 
> * Mariia Mykhailova 
> * Shravan M Narayanamurthy 
> * Dongjoon Hyun 
> * Sergiy Matusevych 
> * Tyson Condie 
> * Chris Mattman 
> * Chris Douglas 
> * Boris Shulman 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Markus Weimer be
> appointed to the office of Vice President, Apache REEF, 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 REEF Project be and hereby
> is tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache REEF Project; and be it further
>
> RESOLVED, that the initial Apache REEF Project be and hereby
> is tasked with the migration 

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

[Ross Gardler]

There should be no recommendation for podlings. Mentors should guide the 
podling to making the right decision for their community by discussing the pros 
and cons of each model.

The idea of a mentor bringing their preference, or worse the IPMC having a 
"default" is problematic.

Sent from my Windows Phone

From: Dennis E. Hamilton
Sent: ‎11/‎6/‎2015 9:35 AM
To: general@incubator.apache.org
Subject: RE: Concerning Sentry: A disagreement over the Apache Way and 
graduation

I think there is a difference between what TLPs do and what the recommended 
approach for Podlings is.

My impression, based on limited podling experience, is that the default tends 
to be PPMC == committer.

Thanks for raising the notion of looking at why committers are *not* moved to 
the PMC of a TLP after some period of time, though.  My question, as a PMC 
member, would be whether or not we are holding the reins too tight at the 
expense of both community and sustainability.  An useful danger sign, that.

 - Dennis

> -Original Message-
> From: Greg Reddin [mailto:gred...@gmail.com]
> Sent: Friday, November 6, 2015 06:22
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
>
> On Fri, Nov 6, 2015 at 7:58 AM, Rich Bowen  wrote:
> > On 11/05/2015 12:02 AM, Joe Schaefer wrote:
> >> Committership is the right to do work on the project. PMC membership
> is the
> >> right to participate in governance.  People left in the nebulous
> state
> >> between
> >> committership and PMC membership for long periods of time more than
> likely
> >> will give up in frustration for not being trusted enough to govern
> their
> >> own work.
> >
> >
> > Most of the older projects at the Foundation do not have PMC ==
> > Committer. Notably, httpd. The notion that committers are
> automatically
> > PMC is a fairly new innovation. As it happens, it's an innovation that
> I
> > wholeheartedly support and recommend, but it's a minority of projects
> > that have this policy. If you follow board reports, you'll notice that
> > PMC additions and Committer additions are seldom coincident.
>
> In further support of Joe's point, for most of the projects I've been
> involved with, the PMC promotion was almost automatic and occurred
> within about 6 months of committership. The committer-only period was
> just a probationary period to make sure a person was not going to
> abuse his/her privileges. An invite to committership comes with an
> unspoken assumption that we want you to help govern the project, but
> let's start with giving you access. I don't know that I ever saw
> anyone stay as committer-only for an extended period of time.
>
> Greg
>
> -
> 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: How to get more mentors on podlings

[Ross Gardler]

Yes, *find* - I certainly can't afford that autocorrect ;-)

Ross

-Original Message-
From: Upayavira [mailto:u...@odoko.co.uk] 
Sent: Saturday, October 24, 2015 2:30 AM
To: general@incubator.apache.org
Subject: Re: How to get more mentors on podlings

I think you mean "find". It could, otherwise, get expensive!!

Upayavira 

On Sat, Oct 24, 2015, at 05:17 AM, Ross Gardler wrote:
> I see this as the Champions role. You could ask for volunteers, and it 
> will get you folks but you really want people who are invested. As a 
> champion I consider it my job to fund such folks.
> 
> Sent from my Windows Phone
> 
> From: John D. Ament<mailto:johndam...@apache.org>
> Sent: ‎10/‎23/‎2015 5:43 PM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: How to get more mentors on podlings
> 
> Based on some the threads floating around I ask this of all.
> 
> How should a podling reach out when they need more active mentors?  I 
> am not saying there needs to be a big process or a small one, but at 
> least some guidance to give to poslongs when they need a boost.
> 
> It seems to me that sometimes we end up with a lot of mentors on easy 
> to complete podlings (groovy is a great recent example).  Harder 
> podlings end up struggling.
> 
> John

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

RE: How to get more mentors on podlings

[Ross Gardler]

I think Ripple is the only one I currently have in incubation where I'm the 
champion. As you can see on the private list the mentors are already silent 
there so you shouldn't have too much of a challenge.

In fact, this is a good example of my response below (s/fund/find). In Feb this 
year I stepped in to help the project get beyond a deadlock. Judging by recent 
activities I might need to step up again.

Ross

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Saturday, October 24, 2015 11:32 AM
To: general@incubator.apache.org
Subject: Re: How to get more mentors on podlings

On Fri, Oct 23, 2015 at 9:17 PM, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> As a champion I consider it my job to fund such folks.


Ross,

Can I get a list of projects you are championing?  I want to figure out how to 
induce the mentors to go silent.

RE: How to get more mentors on podlings

[Ross Gardler]

I see this as the Champions role. You could ask for volunteers, and it will get 
you folks but you really want people who are invested. As a champion I consider 
it my job to fund such folks.

Sent from my Windows Phone

From: John D. Ament
Sent: ‎10/‎23/‎2015 5:43 PM
To: general@incubator.apache.org
Subject: How to get more mentors on podlings

Based on some the threads floating around I ask this of all.

How should a podling reach out when they need more active mentors?  I am
not saying there needs to be a big process or a small one, but at least
some guidance to give to poslongs when they need a boost.

It seems to me that sometimes we end up with a lot of mentors on easy to
complete podlings (groovy is a great recent example).  Harder podlings end
up struggling.

John

RE: When podlings don't file a report

[Ross Gardler]

Your reply is fine, except that your original question was about what happens 
when “If it turns out that the Mentors have been reminding the podling to file 
but nobody's followed through”

In other words mentors have already said “I’m on it” and have already tried to 
fix the problem. Your reply to my solution is addressing a step before that.



Sent from Mail<http://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10





From: Marvin Humphrey
Sent: Wednesday, October 21, 2015 5:57 PM
To: general@incubator.apache.org
Subject: Re: When podlings don't file a report


On Mon, Oct 19, 2015 at 1:39 PM, Ross Gardler
<ross.gard...@microsoft.com> wrote:
> This is one aspect that I feel needs fixing. Currently there are too many
> people who "might" be responsible. What we need is someone who *is*
> responsible. It's initially the mentors, but if (as per your original
> question) a podling has failed to file for 4 months then the mentors are
> clearly dropping the ball or they need assistance in impressing upon the
> podling community how important this is. So who next?
>
> My answer is the IPMC, but then we hit the "too many cooks problem".

I don't think it has to be that way.  All any IPMC Member has to do is check
in on the Mentors by sending an email to, say, private@incubator.  That's what
not happening right now.

If there is at least one Mentor willing to continue, all they have to do is
respond "I'm on it" and either persuade the podling to report the next month
or add a comment to the report themselves.

If there are no Mentors willing to continue, then the IPMC has to work with
the podling to arrange for new Mentors or retire.

I don't see a situation there where "too many cooks" end up arguing about the
proper course of action for very long.  Of course someone might stick their
nose in but if there are active Mentors who just needed a nudge, the situation
ought to be resolved quickly.

> To your "shepherd" point below the term here in the IPMC is different to the
> term at the board level. Board shepherds *are* responsible for following up
> after board meetings. That's where the buck stops.

Indeed, the "shepherd" institution is implemented effectively by the Board
level.  We don't have such shepherds in the Incubator... BUT we do have
Mentors.

Mentors are in fact *better* positioned to offer insight than Incubator
shepherds they follow the podling consistently.  We just squander their
insight, because shepherds own primary responsibility for commenting on the
state of the podling.

It's as if the Board had assigned a Director to watch over a TLP then relied
solely on the Board shepherd for their assessment, forgoing all input from the
Director on-the-ground.

Marvin Humphrey

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

RE: When podlings don't file a report

[Ross Gardler]

+1

Sent from my Windows Phone

From: Ted Dunning<mailto:ted.dunn...@gmail.com>
Sent: ‎10/‎22/‎2015 6:10 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Cc: Marvin Humphrey<mailto:mar...@rectangular.com>
Subject: Re: When podlings don't file a report

On Wed, Oct 21, 2015 at 11:01 PM, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> Your reply is fine, except that your original question was about what
> happens when “If it turns out that the Mentors have been reminding the
> podling to file but nobody's followed through”
>
> In other words mentors have already said “I’m on it” and have already
> tried to fix the problem. Your reply to my solution is addressing a step
> before that.
>
>
At that point, I think that the IPMC chair or delegate should be stepping
in and evaluating the situation.

These cases are very likely candidates for withdrawal in my book because
either

1) the community has dissipated beyond ability to act

or

2) the community has little or no interest in responding

The exceptional case is that the podling leader needs replacement.

These should be more unusual than they are, but it definitely happens.

RE: When podlings don't file a report

[Ross Gardler]

This is one aspect that I feel needs fixing. Currently there are too many 
people who "might" be responsible. What we need is someone who *is* 
responsible. It's initially the mentors, but if (as per your original question) 
a podling has failed to file for 4 months then the mentors are clearly dropping 
the ball or they need assistance in impressing upon the podling community how 
important this is. So who next?

My answer is the IPMC, but then we hit the "too many cooks problem". I'll not 
go into suggestions for fixing this problem as there are plenty of threads 
already looking at how to improve oversight. This is just one of the many 
symptoms of the problem.

To your "shepherd" point below the term here in the IPMC is different to the 
term at the board level. Board shepherds *are* responsible for following up 
after board meetings. That's where the buck stops.

Ross

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Monday, October 19, 2015 1:27 PM
To: general@incubator.apache.org
Subject: Re: When podlings don't file a report

On Thu, Oct 15, 2015 at 10:56 AM, Ross Gardler <ross.gard...@microsoft.com> 
wrote:
> Mentors, in my opinion, are not responsible for their podlings. They 
> are responsible for guiding the podlings but not for filing.
>
> Mentors do have a responsibility to the IPMC to make a recommendation (e.g.
> "I've looked into the failure to report and am happy with the status, 
> it's just busy people this month" or "Looks to me like the podling 
> community don't take reporting seriously. As a mentor I've tried but 
> failed to communicate the importance this.")

When is that responsibility to the IPMC discharged?  Only when a shepherd, or a 
random volunteer, inquires?  If a podling fails to report indefinitely, do we 
have any expectation that its Mentors will act?

I suppose that as an individual volunteer I can start threads about the 
podlings that are not reporting on either private@incubator or 
general@incubator.  It seems wrong to have an independent meddler taking on 
that task, though, instead of the project Mentors.

I think this illustrates again why the "shepherd" institution as implemented by 
the Incubator is pernicious.  Incubator shepherds shouldn't own the task of 
checking up on podlings -- they are unreliable and their responsibility is 
ephemeral.  It should instead be Mentors performing shepherding tasks, since 
Mentors are assigned to podlings durably and are accountable to the IPMC.

Marvin Humphrey

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

RE: When podlings don't file a report

[Ross Gardler]

Mentors, in my opinion, are not responsible for their podlings. They are 
responsible for guiding the podlings but not for filing. 

Mentors do have a responsibility to the IPMC to make a recommendation (e.g. 
"I've looked into the failure to report and am happy with the status, it's just 
busy people this month" or "Looks to me like the podling community don't take 
reporting seriously. As a mentor I've tried but failed to communicate the 
importance this.")

That being said an individual who is both an active member of the projects 
development community and a mentor is as responsible as any other community 
member.

Ross

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Thursday, October 15, 2015 9:42 AM
To: general@incubator.apache.org
Subject: When podlings don't file a report

Greets,

This month, six podlings failed to file a report.  Of those, one has failed to 
file 4 months running, and another two have failed to file for 2 months running.

Filing one month late every once in a while is excusable, but two months or 
more ought to trigger a followup.

If it turns out that the Mentors have been reminding the podling to file but 
nobody's followed through, why not add a comment in the "Mentor comments"
section?  (That's what Rob Weir did this month -- kudos!)  Aren't the Mentors 
part of the podling community and thus sharing in the responsibility for 
reporting?

Marvin Humphrey

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

RE: Mentor disengagement - a suggestion

[Ross Gardler]

Further to Sam's suggestion and observations below see 

Suggestion 0.1.8 at 
http://wiki.apache.org/incubator/IncubatorIssues2013#Suggestions

-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby
Sent: Wednesday, October 14, 2015 7:26 AM
To: general@incubator.apache.org
Subject: Re: Mentor disengagement - a suggestion

On Wed, Oct 14, 2015 at 10:07 AM, Ted Dunning  wrote:
> On Wed, Oct 14, 2015 at 6:46 AM, Jim Jagielski  wrote:
>
>> My point is that with 1 mentor, everyone knows where the buck stops.
>> With >1 nobody knows. A flat hierarchy for mentors does not seem 
>> workable or, at least, optimal.
>>
>
> That's a fine point.
>
> But it is counter to my experience.
>
> For instance, on Kylin, I was extremely active early on. Lately, 
> Julian Hyde has taken much more of the questions.  It has worked very 
> well.  We have a third mentor (whose name I won't mention) who has 
> been nearly completely missing, but that hasn't been a problem since 
> everybody knows that they are totally MiA.
>
>
>> If we wish to address this, and not "force" mentors to leave, we 
>> could simply add the idea of "lead mentor" and have the PPMC vote on 
>> which mentor they want to be the lead mentor (pseudo PPMC chair); the 
>> remaining mentors would remain as co-mentors but the intent is that 
>> the lead mentor would be the primary person responsible.
>>
>
> I think that this is largely process without clear need. But others 
> may have different experience.

The following is from the definition of "champion" on the incubator roles and 
responsibility page[1]:

---
During incubation, the Champion:

 * Coordinates the creation and timely delivery of the podling's board reports.
 * Keeps an eye on the mentors' activity and takes action (ask for new mentors, 
talk to the Incubator PMC) if they don't seem to provide enough oversight or 
mentorship to the podling,
---

First question: does this description match current practice.  Second
question: is there something in that description that needs to get done, but 
isn't getting done?

There also is a separate thread about the number of podlings that the Incubator 
can handle.  That number would tend to increase if some of the work were 
decentralized more.

My take is that (at least for this month) Marvin is effectively doing the first 
bullet for all podlings.  Now I don't see any signs of burnout in Marvin, so 
that's not the immediate concern, but scalability and sustainability would 
benefit from decentralizing this more.

As to the second bullet, it isn't clear to me that that is being done.
Even if it were only a one time thing, reverifying (or in many cases,
naming) the champion for every podling, and then asking each to reverify the 
active status for every mentor for podlings that they champion might go a long 
way toward easing some of the concerns that people have raised.

Ultimately the definition of champion, as posted, should match reality.

- Sam Ruby

[1] 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fincubator.apache.org%2fincubation%2fRoles_and_Responsibilities.html%23Champion=01%7c01%7cRoss.Gardler%40microsoft.com%7c02e20d0e08f54f9c81f408d2d4a356cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=q10OQ8l3N4%2bAPk%2bXJYxZVF1mEREPIOYNpQcD9Frr0rI%3d

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

RE: Possible process improvement?

[Ross Gardler]

Great suggestion, can you modify the templates? All ASF committers have write 
access to the comdev site via the ASF CMS. Only ComDev contributors have commit 
there, so you might want to ping d...@community.apache.org if your change gets 
missed for some reason.

Ross

-Original Message-
From: Dave Birdsall [mailto:dave.birds...@esgyn.com] 
Sent: Wednesday, October 14, 2015 1:07 PM
To: general@incubator.apache.org
Cc: priv...@trafodion.incubator.apache.org
Subject: Possible process improvement?

Hi,



I’m a committer/PMC member on the Trafodion podling.



One thing I’m noticing about the new committer process // 
https://na01.safelinks.protection.outlook.com/?url=community.apache.org%2fnewcommitter.html%23new-committer-process=01%7c01%7cRoss.Gardler%40microsoft.com%7c66849f04a0bc4ba8b82908d2d4d31f77%7c72f988bf86f141af91ab2d7cd011db47%7c1=FEDCimuYkAjQ3SRrQzHJGiaf0WGZtqDTXds0n7LNGh0%3d
 is that we sometimes get hung up on the step, “Request creation of the 
committer account”.



The reason for the hang up often seems to be, the new committer has expressed a 
desire for a particular apache ID, but has not specified where e-mail for that 
ID should be forwarded to.



Now, the iCLA form itself asks for the preferred apache ID. But that form does 
not ask about forwarding e-mail ID. Too, the receipt of the iCLA is forwarded 
to the podling’s private list, but not the iCLA itself.



Also, the committer accept template makes no mention of providing a forwarding 
e-mail address.



So, the mentor has to ask. And the mentor often doesn’t have an e-mail address 
for the new person. So that request has to be relayed through the podling PMC 
private list, and someone there who knows the individual can ask.



I can think of a couple of ways to make this more efficient.



1.   Change the iCLA to include forwarding e-mail address. And when the
iCLA is received, it is shared with the podling private list.

2.   Alternatively, change the committer accept template in //
https://na01.safelinks.protection.outlook.com/?url=community.apache.org%2fnewcommitter.html%23new-committer-process=01%7c01%7cRoss.Gardler%40microsoft.com%7c66849f04a0bc4ba8b82908d2d4d31f77%7c72f988bf86f141af91ab2d7cd011db47%7c1=FEDCimuYkAjQ3SRrQzHJGiaf0WGZtqDTXds0n7LNGh0%3d
 to ask for a forwarding e-mail ID along with asking for the preferred apache 
ID.



Thoughts?



Thanks,



Dave

RE: Mentor disengagement - a suggestion

[Ross Gardler]

+1000 (though I would argue a single highly committed mentor is sufficient)

-Original Message-
From: Julian Hyde [mailto:jh...@apache.org] 
Sent: Tuesday, October 13, 2015 9:46 PM
To: general@incubator.apache.org
Subject: Re: Mentor disengagement - a suggestion

It's not activity on the dev list, or even report signoffs, that matter most. 
Podlings, especially new podlings, have lots and lots of questions, especially 
about infrastructure. Without at least two responsive mentors to field those 
questions you feel like banging your head on the wall. And you start wondering 
why you left the comfort and convenience of github and whether Apache itself is 
fascinated by its own brand.

Before you ask, you won't get podlings to send their questions to another list, 
because we're all too proud to ask questions which in retrospect always turn 
out to be dumb questions.

It's not possible to measure that kind of mentor activity, so I think people 
are inclined to measure the "public" forms of activity as proxy indicators.

Julian


On Tue, Oct 13, 2015 at 4:19 AM, Jim Jagielski  wrote:
> For me, I consider being a mentor as I do being a member of a PMC.
> Occasionally one simply lacks cycles to be actively involved, but one 
> is involve enough to see that others *ARE* involved, and so I am 
> "unconcerned" about my inactivity during those times.
>
> My understanding is that this is OK and its one of the reasons why we 
> *have* multiple mentors.
>
> "Shaming" inactive mentors would be akin to "shaming" PMC members who 
> didn't post on the dev@ list this month, or who didn't vote on a 
> release or etc...
>
> I am not, of course, referring to mentors who are truly MIA month in 
> and month out. But, as someone said, if you remove those from the 
> equation, the list of "active" mentors is pretty constant.
>
> So the question is "Is there a difference or problem between a podling 
> with 10 mentors, of which 4 are 'active', as compared to a podling 
> with
> 4 mentors, all of which are 'active'"??
>
>> On Oct 13, 2015, at 2:29 AM, Ted Dunning  wrote:
>>
>> On Mon, Oct 12, 2015 at 11:05 PM, Sam Ruby  wrote:
>>
 Sounds like reaching out to the inactive mentors is a great idea 
 and I think we have a great example here of how complicated it can be.
>>>
>>> Nope.  I posted that link knowing that my name would be on it, and 
>>> advocated that we should be having exactly this discussion.  I 
>>> should either become more active on this, or (and probably more 
>>> likely) remove myself as a mentor for this podling.
>>
>>
>> And possibly by so doing become a great example to others of us who 
>> can't admit to ourselves that we are over-extended.
>
>
> -
> 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: A question: Is it alright to say no to potential podlings?

[Ross Gardler]

If a project has infra requirements that are not “standard” for the ASF then 
these should, IMHO, be uncovered by the champion/mentors prior to proposal. If 
missed there then the discuss phase should uncover them.



These should then be discussed with the infra team prior to vote.



Ross



Sent from Outlook Mail<http://go.microsoft.com/fwlink/?LinkId=550987> for 
Windows 10 phone





From: Justin Mclean
Sent: Tuesday, October 13, 2015 1:57 AM
To: general@incubator.apache.org
Subject: Re: A question: Is it alright to say no to potential podlings?





Hi,

>  I know I've been a bit worried about Mynewt in that context - not
> enough to think it should be rejected, but enough to be concerned about
> what expectations we're setting, etc.


While I don’t know the exact answer and can;t speak for the project. I don’t 
see too much of an issue here as I assume testing can be done via simulation 
(and not on the target platforms) on currently available infrastructure. PPMC 
members or interested committers / users are likely to have their own hardware 
to validate releases and that hardware is of reasonably low cost ($20-$50 for a 
development board).

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

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

[Ross Gardler]

http://incubator.apache.org/guides/proposal.html#proposal-template

-Original Message-
From: Andrew Bayer [mailto:andrew.ba...@gmail.com] 
Sent: Tuesday, October 13, 2015 8:04 AM
To: general@incubator.apache.org
Subject: Re: A question: Is it alright to say no to potential podlings?

Where is that template kept?

A.

On Tue, Oct 13, 2015 at 10:22 AM, Bertrand Delacretaz < bdelacre...@apache.org> 
wrote:

> On Tue, Oct 13, 2015 at 10:18 AM, Andrew Bayer 
> 
> wrote:
> > ...Would it be reasonable to add a section to the proposal template
> covering
> > infrastructural requirements/expectations?...
>
> You could add a question to the "Required Resources" section of the 
> podling proposals, where podlings have to express any unusual needs.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: [VOTE] Release Apache REEF 0.13.0-incubating (rc1)

[Ross Gardler]

+1 (based only on an IP validation)

The community need to address the items below, but they are not blockers.

Ross

-Original Message-
From: Mariia Mykhailova [mailto:mamyk...@microsoft.com] 
Sent: Tuesday, October 13, 2015 10:52 AM
To: general@incubator.apache.org
Subject: RE: [VOTE] Release Apache REEF 0.13.0-incubating (rc1)

Daniel, thank you for your checks. 
C# files which are missing license headers are autogenerated from corresponding 
Avro/Protobuf files. 
BSD license comes with NSubstitute library.

We could really use two more IPMC votes :-)

-Mariia

-Original Message-
From: Daniel Gruno [mailto:humbed...@apache.org]
Sent: Monday, October 12, 2015 1:32 AM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache REEF 0.13.0-incubating (rc1)

Did the usual checks;
- Sigs, hash etc checks
- unpacks fine
- license, notice present
- Things are apache licensed :)

There are a few C# files missing license headers, see 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcompliance.rocks%2fresult.html%3f23410ea9=01%7c01%7cmamykhai%40microsoft.com%7cff9359a232f34528e89608d2d2df8f56%7c72f988bf86f141af91ab2d7cd011db47%7c1=80r6c4FQ93EmQCmDMbTM65vOHdnGQgPEZuB0yDyHKLE%3d
 - but that's nothing that can't be fixed. I also saw a BSD license but no BSD 
license headers - I'm assuming that's just a third party lib that's not as 
aggressively marking its files as we do.

On the whole, it looks good. I have not tested whether the programs actually 
_work_ - I'll leave that to people who know what REEF is and does :)

+1

With regards,
Daniel.

On 10/10/2015 04:02 AM, Mariia Mykhailova wrote:
> The Apache REEF PPMC has voted to release Apache REEF 
> 0.13.0-incubating based on the release candidate described below. Now 
> it is the IPMC's turn to vote.
> 
> The PPMC vote passed with 5 +1 votes:
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail-a
> rchives.apache.org%2fmod_mbox%2fincubator-reef-dev%2f201510.mbox%2f%25
> 3CBL2PR03MB2900A370B6F6894F8E08EA8D2370%2540BL2PR03MB290.namprd03.prod
> .outlook.com%253E=01%7c01%7cmamykhai%40microsoft.com%7cff9359a232
> f34528e89608d2d2df8f56%7c72f988bf86f141af91ab2d7cd011db47%7c1=i3
> 8mLfYTJE5AgP8Aq3%2bdEh7SxS5F6dJi5fXqOspCwQQ%3d
> 
> 
> The source tar ball, including signatures, digests, etc can be found at:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdist.
> apache.org%2frepos%2fdist%2fdev%2fincubator%2freef%2f0.13.0-incubating
> -rc1%2f=01%7c01%7cmamykhai%40microsoft.com%7cff9359a232f34528e896
> 08d2d2df8f56%7c72f988bf86f141af91ab2d7cd011db47%7c1=2770HKtZBXPX
> lwVJIOKozS1HGRvebcK3tUtqrcu1IJU%3d
> 
> The Git tag is release-0.13.0-incubating-rc1
> 
> The Git commit ID is e1d42e8008d97714a0f7bc303dae37239a10a029
> 
> 
> Checksums of apache-reef-0.13.0-incubating-rc1.tar.gz:
> 
> MD5: 8e0a1cd6c7e17a86abbd32366c8cccac
> SHA512: 
> 8f542aeaf2dc3b241bdcd0d343c607355e1f09e1ca89bbc3431b0cc1f0908479511f60
> 900a91a6731051ffef8af30488eb85df567c32bc2db9d3d91014c4fed7
> 
> Release artifacts are signed with a key found in the KEYS file available here:
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdist.
> apache.org%2frepos%2fdist%2frelease%2fincubator%2freef%2fKEYS=01%
> 7c01%7cmamykhai%40microsoft.com%7cff9359a232f34528e89608d2d2df8f56%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1=%2bLoMFCrTbg1L7KHxTct86LiY1P
> KnCfiY8y4qFlqb1ZU%3d
> 
> 
> 
> Issues Resolved in the release
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> s.apache.org%2fjira%2fsecure%2fReleaseNote.jspa%3fprojectId%3d12315820
> %26version%3d12332972=01%7c01%7cmamykhai%40microsoft.com%7cff9359
> a232f34528e89608d2d2df8f56%7c72f988bf86f141af91ab2d7cd011db47%7c1
> a=poEWHfvnQa6XspM0pGnMl87gnsqXdX%2bge5mcDriIKJs%3d
> 
> 
> The vote will be open for 72 hours. Please download the release 
> candidate, check the hashes/signature, build it and test it, and then 
> please vote:
> 
> [ ] +1 Release this package as Apache REEF 0.13.0-incubating [ ] +0 no 
> opinion [ ] -1 Do not release this package because ...
> 
> Thanks!
> 


-
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: Incubation capacity

[Ross Gardler]

With respect to " I hope that we can manage that a bit by pushing to recognize 
common points of reference, move on to points difference and only then start 
discussing solutions." I remind everyone of a perfect starting point for this - 
perhaps we can focus on constructively updating 
http://wiki.apache.org/incubator/IncubatorIssues2013

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Monday, October 12, 2015 9:26 PM
To: general@incubator.apache.org
Subject: Re: Incubation capacity

I think that this is an excellent analysis.

The (gut) feeling I have about scarce resources are:

1) me.  As Marvin noted, I am a failure mode as much as a contributor lately.  
This is largely due to my crazy travel schedule combined with lots of short 
term deliverables. Marvin has lightened that load enormously with the report 
group and I see that as a good way forward

2) mentors. As Zukka mentions, the number of mentors is roughly constant if you 
subtract away those who are MiA


I worry that the lull that others have noted in drama level may be increasing 
again. I hope that we can manage that a bit by pushing to recognize common 
points of reference, move on to points difference and only then start 
discussing solutions.




On Mon, Oct 12, 2015 at 2:13 PM, Jukka Zitting 
wrote:

> Hi,
>
> On Mon, Oct 12, 2015 at 2:50 PM Marvin Humphrey 
> 
> wrote:
> > On Mon, Oct 12, 2015 at 8:08 AM, Jukka Zitting 
> wrote:
> > > It sounds like ruminations about the Incubator are on the increase
> again,
> >
> > I hope that we can make use of some of this bursting energy and 
> > channel
> it
> > into incremental improvements.
> >
> > The Incubator is a stable platform, and it has been functioning well 
> > by historical terms, and with blessedly low drama compared to a few 
> > years
> ago.
> > My impression is that frustration with the institutional resistance 
> > of Incubator to change is skewing impressions of how well it is 
> > doing its
> job of
> > incubating podlings.
>
> Yes, we're far from the drama of 2011.
>
> > > I believe the way the Incubator is organized sets an upper bound 
> > > on the number of podlings it can effectively manage. Based on 
> > > experience and historical data 
> > > (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fi
> > > ncubator.apache.org%2fhistory%2f=01%7c01%7cRoss.Gardler%40mic
> > > rosoft.com%7c16c58f0566a547707af408d2d3868e32%7c72f988bf86f141af91
> > > ab2d7cd011db47%7c1=6DkLFL2cvSI%2bi9cpO%2fbrzR6vmzQE4xKDInxbq
> > > %2b270bE%3d *) I believe
> this
> > > limit is somewhere around 30 podlings.
> >
> > I'm curious, Jukka.  Why 30?
>
> I don't have a firm theory on why this is happening, only some key
> observations:
>
> * The entry rate of new podlings has been amazingly constant 
> throughout the existence of the Incubator even though the total number 
> of open source projects has been growing exponentially for much of 
> this time.
>
> * The "limit" was first reached in 2006 during which the board first 
> pushed back on Incubator reports and the current monthly 1/3 reporting 
> schedule was adopted and the process of retiring dormant podlings was 
> adopted.
>
> * The Incubator stayed at or slightly above the 30 podlings limit 
> until around mid-2010 after which many podlings started getting stuck, 
> leading to the crisis of late 2011.
>
> * We solved that problem with a concentrated effort in 2012 that 
> brought the Incubator back to around 30 active podlings, a level that 
> stayed mostly stable for the next two years.
>
> * The number of current podlings is again growing, and some of the 
> issues that have shown up recently remind me of the problems seen five 
> years ago.
>
> It could be that I'm just selectively interpreting history to match my 
> theory, but from a systems perspective it does look as if the 
> Incubator indeed has a structural bandwidth cap that probably feeds 
> into and limits the entry rate.
>
> >  What are the scarce resources?
>
> Some possible answers:
>
> * Mailing list. There is only so much general@ traffic that a single 
> IPMC member can reasonably process without starting to skip 
> significant parts.
>
> * Mentors. The growth rate of the IPMC is fairly constant and, with 
> most members becoming inactive over time, I believe the number of 
> active mentors has not grown too much over the years.
>
> * Chair/Report Manager. Someone still needs to pay attention to 
> everything that's going around, which I believe you and all other 
> recent chairs agree is a daunting task.
>
> One could run some numbers to better quantify the above possibilities.
>
> > And how is this supposed degradation manifesting?
>
> The noise got loud enough to wake me up. :-) I don't have hard 
> numbers, but we do have a couple of recent failures and it sounds like 
> some people are getting concerned, which does remind me of early 2011.
> Of course 

RE: Require projects to have solid API docs

[Ross Gardler]

No. That’s not the role of the foundation. However, ensuring people 
contributing to the docs are recognized like any other contributor is the role 
of the foundation. Can you help contribute to such docs?



Sent from Outlook Mail for 
Windows 10 phone





From: Andrew Pennebaker
Sent: Sunday, October 11, 2015 8:59 AM
To: general@incubator.apache.org
Subject: Require projects to have solid API docs


In the future, could Apache Incubator require projects to maintain better
API documentation before graduation? In particular, Kafka has rather sparse
documentation in v0.8. The Javadocs appear to be randomly hosted on this or
that professor webpage, and no Kafka javadoc has documentation for
*both* Consumers
and Producers.

--
Cheers,
Andrew

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I blogged on this topic some time ago - basically it is my opinion that if I am 
a good employee I would never try to contribute code to an Apache project that 
is not beneficial to the broader community. Such an action would be detrimental 
to her employers business. Consequently, there is no conflict between employer 
needs and community needs an ASF project. 

Here's a relevant excerpt:

"Jane is paid to deliver results for her employer. If Jane finds that the best 
route to delivery is through community led open source she ought to fight for 
the survival of that community at all costs. It is in her interests to do so, 
both for her community reputation (employability beyond her current role) and 
for her employers satisfaction (employability in her current role). If Jane 
blows her community reputation she loses her ability to deliver for her 
employer as well as her ability to seek alternative employment relating to that 
community’s activities. A double whammy."

Full blog at 
http://www.computerworlduk.com/blogs/apache-asserts/apache-openoffice-can-i-depend-on-software-built-by-volunteers--3570412/

-Original Message-
From: Reto Gmür [mailto:r...@apache.org] 
Sent: Sunday, October 11, 2015 9:53 AM
To: general 
Subject: Re: [DISCUSS] Mentor neutrality policy

On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
wrote:

> On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  wrote:
> > Hi Incubator folks,
> >
> > I would like to propose we adopt a mentor neutrality policy for 
> > incubating podlings:
> >
> > - A mentor must not be financially tied to the project or its 
> > incubation status.
>
> I'm very strongly -1 on this for two reasons. One fundamental and one 
> operational. Fundamentally, this goes against a core ASF principle 
> that we all collaborate here as individuals by checking our corporate 
> affiliation at the door.


I think it's naive to think that just because the members are individual and 
corporate affiliations don't formally play a role there is no influence by the 
employer. When I'm paid by a company or government agency to work on an apache 
project I don't have an effective protection against the directives of my 
employer. Maybe if I refuse to follow an employer's instruction to write some 
code for an Apache project of which I'm committer I could not be fired without 
notice, maybe I could write the patch and say on the list that I wrote this 
patch for my employer but that as an individual PMC member I vote against it 
(did something like this ever happen?), whichever way I'm likely to act against 
my financial interest.

In medical journals the author's are also writing in their own name, yet they 
must declare all competing interests. Following your logic such as declaration 
would be unnecessary if the journal says somewhere that authors leave their 
affiliation at the door.



> IOW, we are explicitly granting our members and committers the trust 
> required to make sure they do the right thing while they themselves 
> (or their employees) can significantly benefit (financially and 
> otherwise) from the projects.
>

Even if we trust our commiters that they do not commit a hidden back door on 
behalf of the spy agency they work for, the conflict of interest can be much 
more subtle. The company has a deadline and a release of an apache project 
before that deadline would come in very handy, will you scrutinize the notice 
files at the risk of finding something that delays the release?

If a main customer of my consulting firm is the main promoter of the XY file 
format, will I by neutral in choosing the best file format for the Apache 
Project I'm involved in? I probably really believe that XY is the way to go, 
but is should be an Apache rule that I declare that I have some financial ties 
to it.


>
> This is what makes ASF unique and anything that goes even slightly in 
> the direction of reducing this level of trust will have me up in arms 
> (regardless of whether it is related to Incubator or not).
>
> Operationally, this is extremely tricky to enforce. I speak here from 
> experience of somebody who has to be appreciative of the same set of 
> issues while consulting for companies and yet working for my current 
> employer. Even in a corporate world (where stakes are much higher from 
> legal perspective) this typically gets handled by trusting the 
> individual to do the right thing and disclose any potential conflict 
> of interest (financial or otherwise).
>

We would not have to ask people for their tax declaration, a self declaration 
of any potentially competing interest would do.

Cheers,
Reto

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I said *better* not *more*

-Original Message-
From: Alan D. Cabrera [mailto:l...@toolazydogs.com] 
Sent: Sunday, October 11, 2015 2:34 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentor neutrality policy


> On Oct 9, 2015, at 8:36 AM, Ross Gardler <ross.gard...@microsoft.com> wrote:
> 
> Personally I would focus more on better oversight of podling and mentor 
> activity. The goal is to catch the occasional problem case rather than put 
> restrictions in place. I'm not sure how to do that though. I and others have 
> made many suggestions over the years. They can be found here 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwiki.apache.org%2fincubator%2fIncubatorIssues2013=01%7c01%7cRoss.Gardler%40microsoft.com%7c4cfeaa7504884d70efa608d2d283c20b%7c72f988bf86f141af91ab2d7cd011db47%7c1=XT5hhkPTaOjf68%2bBLa3fV7bfz9zWJSDvmoR8YQXkjcY%3d
>  
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwiki.apache.org%2fincubator%2fIncubatorIssues2013=01%7c01%7cRoss.Gardler%40microsoft.com%7c4cfeaa7504884d70efa608d2d283c20b%7c72f988bf86f141af91ab2d7cd011db47%7c1=XT5hhkPTaOjf68%2bBLa3fV7bfz9zWJSDvmoR8YQXkjcY%3d>
>  (you might want to add your proposal there).

Even more oversight?  We already have a role that provides oversight of the 
shepherds who provide oversight of the mentors who provide oversight of the 
podling.  Spreading responsibility for getting something done is a sure way to 
make sure that it does not get done.  Just my 2 cents.


Regards,
Alan


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

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

No. Meaning that starting from a place of no-trust in an environment where 
trust is critical is wrong.

Ross

-Original Message-
From: Pierre Smits [mailto:pierre.sm...@gmail.com] 
Sent: Friday, October 9, 2015 2:26 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentor neutrality policy

Meaning: proactively trying to doing the right thing, trying to define 
boundaries before wrongdoing happens, is wrong?

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2foem.ofbizci.net%2foci-2%2f=01%7c01%7cRoss.Gardler%40microsoft.com%7ce3df44d6e18b409c180c08d2d0f042cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=jTO4UHTjBVDxUGUNMAPv5ocD5hBmTU0Xj9xM1PTNWEk%3d

On Fri, Oct 9, 2015 at 10:51 PM, Chris Douglas <cdoug...@apache.org> wrote:

> Daniel-
>
> If you have these concerns about mentors, a TLP proposal, or even an 
> active TLP substantiated only by private information: notify the board 
> via board-private@. That's why it's there.
>
> The proposal accuses mentors of selling influence, and acting contrary 
> to the foundation's interest. That is by definition a problem to which 
> we react, with proof of guilt. "Proactively" treating volunteers as 
> suspect demands that mentors prove their innocence. Assuming guilt is 
> not "proactive," but uncivil and immoral.
>
> There are also practical objections. Every IPMC member has a binding 
> vote on decisions made by the incubator, period. IPMC members may 
> voluntarily recuse themselves, but a policy that suppresses the votes 
> of "suspicious" groups is invalid.
>
> The TLP resolution is only recommended by the IPMC. Anything achieved 
> by this proposal is better implemented by the board considering that 
> recommendation in context- including evidence provided privately- and 
> rejecting improper proposals with actionable feedback to the PPMC. -C
>
> On Fri, Oct 9, 2015 at 11:36 AM, Daniel Gruno <humbed...@apache.org>
> wrote:
> > Does there always have to be an actual problem before we can propose 
> > a policy? must we always be reactive instead of proactive?
> >
> > Yes, I am in a way implying that some mentors are, perhaps, not 
> > neutral in their work. I will not back it up with specific names or 
> > contexts, as I don't want to take a trip to lawsuit town for things 
> > I cannot back up with publicly available information.
> >
> > I don't find this to be uncivil accusations - can you outline a 
> > specific segment that you find uncivil? I am proposing a set of 
> > basic rules - which is naturally up for discussion and improvement - 
> > that would potentially alleviate us from having some nasty 
> > discussions - whether they be public or private - about the 
> > neutrality and honesty of recommendations, and hopefully ensure we 
> > have a more leveled playing field in the incubator.
> >
> > I'll stop here, as my eyesight is playing a trick on me today and 
> > not allowing me to see what I type.
> >
> > With regards,
> > Daniel.
> >
> > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> >> What problem does this solve?
> >>
> >> This proposal lacks context. It implies that mentors are not 
> >> neutral, and that they are motivated by interests not shared by the 
> >> ASF. But it does not outline the merits of that belief, neither 
> >> does it specify how this proposal would address them. Instead of 
> >> allowing those definitions to float, this discussion would be more 
> >> productive if it were about some concrete problems for which there 
> >> is evidence. Yet another thread of rude responses to uncivil 
> >> accusations is unproductive, even if it is an IPMC tradition. -C
> >>
> >> On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno <humbed...@apache.org>
> wrote:
> >>> Hi Incubator folks,
> >>>
> >>> I would like to propose we adopt a mentor neutrality policy for 
> >>> incubating podlings:
> >>>
> >>> - A mentor must not be financially tied to the project or its
> incubation
> >>> status.
> >>> - A mentor must not have a vested interest in incubating, 
> >>> graduating or dismantling a podling that goes beyond the general 
> >>> Apache mission
> >>> - A mentor must not be affiliated with the entity granting the 
> >>> code (company or original project community)
> >>>
> >>> Furthermore, I would like to see this extended to votes on 
> >>> graduating
> or
> >>> retiring podlings, so that only peo

RE: [DISCUSS] Mentor neutrality policy

[Ross Gardler]

I'm not sure about this.

In the past I've argued that we need mentors who *do* have a personal interest. 
Those are the ones least likely to be absent during incubation.

I do agree that mentors must act in a neutral way. I would hope that if this 
were not the case then someone would speak up. I accept that it would be 
awkward to do so but concerns need not be raised in a "person Foo is not acting 
in a neutral way" in most cases it would always be possible to say "the project 
is not acting in a neutral way".  

Furthermore, how do we evaluate "vested interest". If someone agrees to mentor 
a project that is from a team in a different part of their company do they have 
a vested interest? Speaking personally I have more interest in the success of 
our partners than I do in some unrelated parts of my employers business. Does 
that mean I should not be allowed to mentor projects from my partners too? 
While I can hide behind a "big company blindness" case others have no such 
option. What if they are from a SME who does not have that luxury, how do we 
enforce this proposal fairly?

I'd like to think that if the ASF is the right place for a project in which 
someone has a vested interest then they will want that project to operate as an 
Apache project. By definition that means that the mentor must act impartially 
if they are to achieve their goals.

Personally I would focus more on better oversight of podling and mentor 
activity. The goal is to catch the occasional problem case rather than put 
restrictions in place. I'm not sure how to do that though. I and others have 
made many suggestions over the years. They can be found here 
http://wiki.apache.org/incubator/IncubatorIssues2013 (you might want to add 
your proposal there).

Ross

-Original Message-
From: Daniel Gruno [mailto:humbed...@apache.org] 
Sent: Friday, October 9, 2015 8:07 AM
To: general@incubator.apache.org
Subject: [DISCUSS] Mentor neutrality policy

Hi Incubator folks,

I would like to propose we adopt a mentor neutrality policy for incubating 
podlings:

- A mentor must not be financially tied to the project or its incubation status.
- A mentor must not have a vested interest in incubating, graduating or 
dismantling a podling that goes beyond the general Apache mission
- A mentor must not be affiliated with the entity granting the code (company or 
original project community)

Furthermore, I would like to see this extended to votes on graduating or 
retiring podlings, so that only people with no organizational (aparty from the 
ASF) or financial ties to the project (or the companies behind
it) can cast a binding vote on graduation or retirement.

This would essentially mean:

- If you work for a company (or are hired as consultant/advisor) that is 
entering a project into incubation, you cannot mentor it nor vote for/against 
its incubation, graduation or retirement.
- If you are a in the original community behind the project, you cannot mentor 
it nor vote for/against it.

I believe this would create a neutral mentorship whose sole mission is to guide 
podlings with the interests of the ASF in mind.


Please do discuss this. If there is (mostly) positive feedback, I would like 
to, at some point, have a vote on including this in the Incubator policy. I 
realize this would cut down on the number of potential mentors, and I would ask 
that more people step up to the challenge of mentoring if adopted.

With regards,
Daniel

-
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: Should Apache VOTEs be in a first-come, first-serve queue?

[Ross Gardler]

+1 and given further comments from Tinkerpop community representatives I would 
say the mentors need to step up and explain what Apache is all about.

Ross

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, September 15, 2015 8:49 AM
To: Incubator General <general@incubator.apache.org>
Subject: Re: Should Apache VOTEs be in a first-come, first-serve queue?

On Mon, Sep 14, 2015 at 6:26 PM, Marko Rodriguez <okramma...@gmail.com> wrote:
> ...the project committee is left "hoping" that someone will care --- 
> pinging around to their mentors (no reply)...

This is your actual problem - a podling needs active mentors to operate.

-Bertrand

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

RE: Should Apache VOTEs be in a first-come, first-serve queue?

[Ross Gardler]

If you want the legal protection of the foundation then you need to learn to 
respect and understand why we work the way we do. That's what gives you legal 
protection.

Voting +1 on a release is an indication that best effort due diligence has been 
conducted on the release. It takes time and effort. I hope everyone who ever 
votes +1 on any release does so after doing the required IP audit.

Anything less is doing you and Tinkerpop a disservice despite your lack of 
respect for the community approach to developing software that we advocate 
alongside strong IP management policies.

Ross

-Original Message-
From: Marko Rodriguez [mailto:okramma...@gmail.com] 
Sent: Monday, September 14, 2015 7:41 PM
To: general@incubator.apache.org
Subject: Re: Should Apache VOTEs be in a first-come, first-serve queue?

Hi,

> Thanks for making a clear statement because it lets me focus on the 
> question that may be central to this discussion: can you tell us why 
> did you guys decided to join ASF in the first place? This is not a 
> baited
> question: I'm genuinely curious about what kind of expectations did 
> you have when joining and what did you want to achieve?
> 
> Because, you see, a project that's part of the foundation can't simply 
> be just 'using' the foundation, it actually has to become part of the 
> foundation, in my mind.

For me personally, I wanted TinkerPop to be apart of Apache because no one has 
won a lawsuit against Apache and I wanted that protecting me and my code as an 
open source software developer.
---


>> I don't expect the users of TinkerPop to have to write my code, they 
>> are there to use it.
> 
> Well, that a bit black-n-white. Certainly folks who don't want to 
> write TinkerPop code can't be forcefully compelled to do so. Yet, 
> somehow, the way you phrased it makes me suspect that you see it as a 
> firewall between the two communities of users vs. developers. Am I 
> reading this wrong?

99.% of people using TinkerPop are not submitting bug reports, pull 
requests, ideas, community "votes" on directions, @Deprecation decisions, etc. 
I do not have any fantasies that these people should participate in a 
bi-directional engagement with TinkerPop. Why should they, they are using the 
software to solve their particular problems and could care less about the 
"TinkerPop community" as long as those releases (bug 
fixes/optimizations/features) keep coming.
---


> 
>> If I'm not delivering software in a timely manner,
> 
> *you* (as in Marko Rodriguez) are not delivering software. Your entire 
> development community does. It is a subtle but important distinction 
> that goes to heart of the Apache Governance model: we don't allow 
> BDFLs. Anyone who's part of your community can propose a release at 
> any time.

No, I deliver software. Likewise, other committers on TinkerPop are delivering 
software. Every piece of code written TinkerPop is not an exercise in pair 
programming. Its "I'm going to knock X, Y, Z out... give me 24 hours before 
touching that module on master/." To which people typically reply: "Sweet. Good 
luck and thanks for taking the reigns on that one." So, I go about delivering 
-- and I do it on time, documented, and tested. Why, cause I wear the TinkerPop 
hat and if I'm say I'm TinkerPop, guess what --- you are going to witness me 
Tinker that Pop. There is no "Marko, you said would work on that...can you 
please get it done? Please... Comon... At least respond to my emails."  And 
I don't use the "I volunteer" excuse as a way of getting out of having to do 
things I implicitly promise to do. If I wear that hat, I do the job the hat 
entails. And guess what, I'm not "busy" either.

---

>> Likewise for Apache Incubation (though perhaps I'm naive in my 
>> assumptions) -- if you are a mentor, move the artifacts through in a 
>> timely manner and don't wait for the project leaders to ping "Hey, can we 
>> get a VOTE?...please...pretty pleasehello?"
> 
> That's a very legitimate point. As Ross mentioned a couple of times if 
> there's one actionable AI from this thread this would be feedback to your 
> mentors.
> Your mentors are your first line of defense on things like release VOTES.
> That said, they are not the only line of defense. Any IPMC member can 
> vote on your release. But the trick is -- you've got to incentivize 
> them somehow.
> And no -- $20 won't cut it and is morally wrong. What will cut it is 
> paying it forward perhaps along the lines that Marvin suggested.

Through my emails here, TinkerPop got the VOTE so my incentivizing-technique 
worked --- troll the list and get people fired up. I suspe

RE: Should Apache VOTEs be in a first-come, first-serve queue?

[Ross Gardler]

Like I said, your mentors are supposed to help you get the required binding 
votes. The problem is not one of the voting process.

-Original Message-
From: Marko Rodriguez [mailto:okramma...@gmail.com] 
Sent: Monday, September 14, 2015 2:52 PM
To: general@incubator.apache.org
Subject: Re: Should Apache VOTEs be in a first-come, first-serve queue?

Hello,

> The Apache motto is "community over code". This means that Apache is 
> all about building community and trusting that the community will 
> build the code. If you don't have the community, then the code doesn't much 
> matter.

We have a community of users and vendors that leverage our software and push us 
to get our releases out in a timely manner. As such, we are working for our 
community, we just can't seem to get our artifacts through in a timely manner 
within the Apache Incubation process. Our PMC reviews and votes go smoothly at 
dev@, but then we hit the general@-wall and we twiddle our thumbs "hoping" 
someone will VOTE. And as a great man once told me: "Hope is not a strategy."

> There may be issues with the incubator, the voting systems and such, 
> but it isn't a bug that humans are involved and need care and feeding 
> to get them motivated.  That is a feature.

I comment on this below.

> I think that Marvin's question to you was pretty cogent. Would you be 
> willing to spend an hour or so each on 5 different projects you aren't 
> involved in before getting to put your own project up for a release? 
> Would it change your willingness if most of the community behind some 
> of those projects not only aren't willing to review your project, but 
> they aren't even willing to review their own project carefully and cast a 
> vote?

I use Apache, I am not Apache. I don't expect the users of TinkerPop to have to 
write my code, they are there to use it. If they find a bug, I ask that they 
submit a bug report (or better yet, a pull request). I map that to here:

"voting is inefficient and human biased" => bug report
"why not use a voting queue" => pull request

If I'm not delivering software in a timely manner, then I'm not doing my job. 
If I'm going to wear the TinkerPop hat, then I better deliver on TinkerPop or 
take off that hat. Likewise for Apache Incubation (though perhaps I'm naive in 
my assumptions) -- if you are a mentor, move the artifacts through in a timely 
manner and don't wait for the project leaders to ping "Hey, can we get a 
VOTE?...please...pretty pleasehello?"

> Your answers will likely say a lot about the dynamics of getting 
> people to help each other. It is hard to do and a human touch goes 
> further than setting hurdles.

This is where I lose you guys. Why are humans involved in a process that should 
be automated.

1. MD5, SHA1, PGP can be automatically checked.
2. Unzip and see if the data is corrupted can be done automatically.
3. LICENSE verification is difficult, but I suspect with some markup 
language for LICENSE and pom.xml analysis, this can be done automatically.
4. mvn clean install (BUILD SUCCESS can be verified automatically).
5. ...

As I see it, get the human out of the loop so we can move some software. Next, 
I suspect you guys are getting tired of my banter. What better way to get rid 
of me than to get this process automated so there isn't a sense of "dude, this 
Marko guy bugs. I'm not wasting my time helping him." Once people start 
thinking like that then its not about software, its about 
politicsmarketing. Politics aren't processing rippin' the algorithms, 
software is.

Thanks guys,
Marko.

https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmarkorodriguez.com=01%7c01%7cRoss.Gardler%40microsoft.com%7c3439ea78ec374bbb350f08d2bd4e9c42%7c72f988bf86f141af91ab2d7cd011db47%7c1=1xAts1zjVEJyW9cfBKYB2EOEsL1DNMcE9QT6Hz%2b15uI%3d


> 
> 
> 
> 
> 
> 
> 
> On Mon, Sep 14, 2015 at 12:45 PM, Marvin Humphrey 
> 
> wrote:
> 
>> Hi Marko,
>> 
>> Have you ever considered reviewing other podlings' incubating release 
>> candidates and cast non-binding votes yourself?  If podling 
>> contributors like you would all help each other by performing 
>> thorough inspections of each others release candidates (and by 
>> learning enough to perform those thorough inspections), it would make 
>> things easier for everyone!
>> 
>> I'm sure that some people reading this list are chortling with 
>> contempt at my naivete.  ("Why not?  Because there's nothing in it 
>> for ME, dummy!")  But helping out with other people's projects was 
>> part of what got me elected onto the IPMC while Lucy (the main 
>> project I contribute to) was still incubating.
>> So then I was able to cast binding votes -- and our podling was 
>> largely insulated from the problem that so vexes you now.
>> 
>> Participating in wider Apache activities is also its own reward.  The 
>> Apache Software Foundation is a worthy institution