date:20150105

For your reading and wrangling pleasure, I offer:
https://wiki.apache.org/incubator/IncubatorV2.

The goal of this exercise is to turn the idea of the pTLP into a
practical alternative. By 'practical', I mean: 'based on the
constraints as I see them'; the board and comdev are not going to find
a little bottle labelled 'drink this' and swig away at new
responsibilities.

I'm not offering this to advocate for it, or against it. My purpose is
more to argue that it would be a ton of work. 'Mentors in the Project'
in the existing, messy, noisy, IPMC would be a lot less work and has
the potential to deliver comparable results on the important issues.

But if people want to take this up, or if someone wants to campaign
for chair using this as a platform, that would be more productive that
discussing the pTLP alternative in the abstract.

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

Re: pTLP, concretely

On Mon, Jan 5, 2015 at 8:41 AM, Alan Cabrera l...@toolazydogs.com wrote:


 On Jan 5, 2015, at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:

 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com wrote:

 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2. ...

 IIUC the main difference (besides subtle naming changes) is that pTLPs
 vote on their own releases, based on pTLP PMC members who have been
 accepted by the board?

 So more work for the board, and each pTLP needs to form an acceptable
 PMC roster with at least 4-5 members?

 My thoughts exactly. What this proposal effectively does is pawn off the 
 responsibility of holding mentors accountable to the board.

No. The original uncooked pTLP scheme did that. This scheme locates
that responsibility in the renamed committee, which serves the board
by supervising the pTLPs. They aren't mentors, they are PMC members.






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


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

Re: Incubator report sign-off


 On Dec 29, 2014, at 6:40 AM, Rich Bowen rbo...@rcbowen.com wrote:
 
 3. patch the current process with starting to drop the mentors from
 the project who don't sign off. This will essentially serve
 as a heartbeat for mentors (now, in my opinion it'll quickly
deteriorate into mindless tick-offs -- but at least it does not harm).
 
 
 ... who don't sign off N times, perhaps? Missing one should be a warning, two 
 a scolding, three the boot, perhaps?


+1


Regards,
Alan

Re: pTLP, concretely


 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com wrote:
 
 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2.
 
 The goal of this exercise is to turn the idea of the pTLP into a
 practical alternative. By 'practical', I mean: 'based on the
 constraints as I see them'; the board and comdev are not going to find
 a little bottle labelled 'drink this' and swig away at new
 responsibilities.
 
 I'm not offering this to advocate for it, or against it. My purpose is
 more to argue that it would be a ton of work. 'Mentors in the Project'
 in the existing, messy, noisy, IPMC would be a lot less work and has
 the potential to deliver comparable results on the important issues.
 
 But if people want to take this up, or if someone wants to campaign
 for chair using this as a platform, that would be more productive that
 discussing the pTLP alternative in the abstract.


IMO, the “noise” comes from the IPMC discussing new processes, roles, etc., 
when mentors fail to do their jobs.

This proposal is essentially a re-boot with the hopes that bad mentors don’t 
make it into the new world order.

What we really need is less rules, less trial bureaucracy mechanisms, less 
roles, and simple mechanisms to hold mentors accountable to the task that they 
signed up to perform.


Regards,
Alan


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

Re: Incubator report sign-off


 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
1. get rid of IPMC altogether and move to the pTLP model

This is effectively an IPMC reboot.  I don’t really see anything substantially 
different. 

2. make this a poddling issue: if a poddling fails to hunt down ALL
the mentors for a sign-off -- reject its report

This tactic has no teeth.  If the mentors are MIA do you think that they would 
care if a report were rejected?

3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
   deteriorate into mindless tick-offs -- but at least it does not harm).

How is it that a mentor became an IPMC member and do such an unethical thing 
such as a mindless tick-off?


Regards,
Alan

Re: Incubator report sign-off


 On Dec 19, 2014, at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote:
 
 I noted in my comments on the recent Incubator board report that I am 
 concerned, month after month, at the number of podlings that have no mentor 
 sign-off at all, as well as the ones where a minority of the mentors sign-off.
 
 I certainly don't expect that every mentor has their full attention on a 
 podling every month, but I do expect that a podling that cares about its 
 incubation will seek out that mentor sign-off, and that the mentors who have 
 committed to help a podling into the family will have a few moments every few 
 months to look in and approve a report.
 
 The result, unfortunately, is that we have projects graduating with no notion 
 of the importance of reporting, and so we have TLPs that look at reporting as 
 a checkbox, submit exactly the same cut-and-paste report each month, some of 
 them without even changing stats and dates, or skip their reporting entirely.
 
 I don't mean to point fingers here - this is a problem that has existed 
 literally since the beginning of the Incubator, and I'm not innocent of it 
 myself. Indeed, I don't show up often enough even on this list.
 
 But I wonder if we might, as the Board does, reject reports that have no 
 sign-off, and force projects to report again the following month, in an 
 attempt to require them to engage with their mentor(s) a little more? This 
 seems like a small, easily reversible, step, that has a good chance of 
 achieving something.
 
 Thoughts?


A while back I proposed to make the podlings and mentors accountable.

Podlings would be required to have a minimum of two active mentors.  A mentor 
is free to become inactive but must explicitly state this else the mentor risks 
being removed for not performing their duties.  Podlings that do not have the 
minimum of two active mentors are put on hold until they find enough mentors to 
fill the quota.  Being put on hold means that no committers can be added, no 
PPMC members can be added, and no releases can be performed.  It does not stop 
development.

Mentors who do not review and vote on a podlings releases are marked inactive.

Mentors who do not review and sign board reports are marked inactive.


Regards,
Alan

Re: Volunteer to Shepherd


 On Dec 18, 2014, at 9:32 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Thu, Dec 18, 2014 at 7:53 PM, Marvin Humphrey mar...@rectangular.com 
 wrote:
 On Thu, Dec 18, 2014 at 7:33 PM, P. Taylor Goetz ptgo...@apache.org wrote:
 
 I’d like to volunteer to help out as a shepherd.
 
 Super! I hope you find the experience broadening.
 
 Huge +1 to that! We are always in need of shepherds.

My perspective, the entire IPMC cannot hope to mentor every podling and so that 
task is assigned to mentors.  Now, since there is no accountability for the 
mentors we have shepherds to monitor the mentors; if we always had fantastic 
mentors the relatively new role of shepherds would not exist. 

Now, we must monitor the shepherds.  Effectively monitoring the monitors who 
monitor the monitors who monitor the podlings…

We are placing our focus on the wrong problem, jmho.


Regards,
Alan


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

Re: Incubator report sign-off

2015-01-05 Thread Mark Struberg

 Our goal as a foundation is not to
 be large, it is to be high quality.


+100 !oneoneone :)

The problem is that sub-par technical contributions quickly lead to community 
issues as well. Please all ask yourself: would YOU like to contribute to a 
project where you have to look at every single commit someone does because they 
often are not of the quality you would expect from an ASF project? And imagine 
what the community effect is if you need to clean up after every other commit 
someone does. 

Sometimes it gets better over time, sometimes it doesn't. In any case it's very 
time consuming and to be a proper mentor we imo cannot just glimpse over the 
project but we need to dig under the skin of it.


It might not be needed to know all the subtle details of the project you are 
mentoring. But you must at least get a feeling if something technically and 
community wise has a bad taste. Often this can be fixed by real mentoring (not 
in the ASF but in the literal sense) and sometimes we probably also need to use 
the emergency exit.


LieGrue,
strub




 On Friday, 19 December 2014, 20:01, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
  Strawman:
 
 What if a mentor is *required* to be an active participant of the project. 
 That 
 is contributing code, voting on releases and generally engaging with the 
 community, they would be a better mentor since they have a vested interest in 
 the project itself. Sure, we might reduce the number of projects coming into 
 the 
 foundation but (IMHO) that is not a problem. Our goal as a foundation is not 
 to 
 be large, it is to be high quality.
 
 Maybe we should simply scrap the idea of mentors and change the role 
 of the champion to one of an initial committer who will help build 
 an Apache project as it incubates and into being a TLP.
 
 We could scrap the role of shepherd and change the role of mentors. A team of 
 9 
 mentors would meet monthly to review *all* podlings reports (as submitted by 
 the 
 champion). Their responsibility is not to engage with the projects but to 
 review 
 the reports crafted by the champion. Any follow up actions would be taken by 
 a 
 single mentor and podlings (especially the champion) are expected to address 
 the 
 issues raised.
 
 If a champion's priorities change during the course of incubation then the 
 project must find another champion (potentially from within their own ranks) 
 who 
 is sufficiently qualified and committed to take on the responsibility. The 
 important thing is that the Champion is personally invested in seeing the 
 podling succeed and acts as a true mentor (as opposed to someone with a title 
 and an entry on a web page). The champion is still answerable to the podling 
 community. Where conflict arises within the community they can call upon the 
 IPMC mentoring team to ask for independent guidance.
 
 This model is almost identical to the way the board and TLPs work (where 
 Champions are roughly equivalent to PMC Chairs and mentors (nee shepherds) 
 are 
 roughly equivalent to Directors and he monthly meeting is roughly equivalent 
 to 
 the monthly board meeting to review TLP reports). I've designed it this way 
 (and proposed the same solution before) because it is proven to work for TLPs 
 and we have tooling to assist with the process.
 
 I look forward to the PMC tearing this strawman proposal apart and (most 
 importantly) suggesting alternatives and/or tweaks of value. We've been 
 skirting this issue for far too long. Things have improved (thanks to all who 
 have worked hard on this), but we have not yet solved the problem.
 
 Ross
 
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 
 -Original Message-
 From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
 Shaposhnik
 Sent: Friday, December 19, 2014 10:11 AM
 To: general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 Hi Rich!
 
 Thanks for raising this point and giving us a bit more of a forcing function 
 to 
 tackle an old problem: accountability for mentors.
 
 On Fri, Dec 19, 2014 at 9:10 AM, Rich Bowen rbo...@rcbowen.com wrote:
  I certainly don't expect that every mentor has their full attention on 
  a podling every month, but I do expect that a podling that cares about 
  its incubation will seek out that mentor sign-off, and that the 
  mentors who have committed to help a podling into the family will have 
  a few moments every few months to look in and approve a report.
 
 I've been thinking about this for quite some time (and trying to seek a 
 solution by various means) and it seems to be that we have to start from a 
 very 
 basic expectation setting.
 
 First of all, *my* expectation is that multiple mentors on the project are 
 more 
 of redundancy or HA consideration. IOW, my expectation that a project needs 
 to 
 have at least one active mentor at all times, but it doesn't have to be the 
 same person. Thus, I

Re: pTLP, concretely

On 5 January 2015 at 14:16, Alan D. Cabrera l...@toolazydogs.com wrote:


  On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com
 wrote:
 
  For your reading and wrangling pleasure, I offer:
  https://wiki.apache.org/incubator/IncubatorV2.
 
  The goal of this exercise is to turn the idea of the pTLP into a
  practical alternative. By 'practical', I mean: 'based on the
  constraints as I see them'; the board and comdev are not going to find
  a little bottle labelled 'drink this' and swig away at new
  responsibilities.
 
  I'm not offering this to advocate for it, or against it. My purpose is
  more to argue that it would be a ton of work. 'Mentors in the Project'
  in the existing, messy, noisy, IPMC would be a lot less work and has
  the potential to deliver comparable results on the important issues.
 
  But if people want to take this up, or if someone wants to campaign
  for chair using this as a platform, that would be more productive that
  discussing the pTLP alternative in the abstract.


 IMO, the “noise” comes from the IPMC discussing new processes, roles,
 etc., when mentors fail to do their jobs.

 This proposal is essentially a re-boot with the hopes that bad mentors
 don’t make it into the new world order.

 What we really need is less rules, less trial bureaucracy mechanisms, less
 roles, and simple mechanisms to hold mentors accountable to the task that
 they signed up to perform.

+1, and dont forget, while keeping the good parts of
incubatorespecially the work around learning the apache way.

rgds
jan i



 Regards,
 Alan


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

Re: pTLP, concretely

 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com wrote:

 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2. ...

IIUC the main difference (besides subtle naming changes) is that pTLPs
vote on their own releases, based on pTLP PMC members who have been
accepted by the board?

So more work for the board, and each pTLP needs to form an acceptable
PMC roster with at least 4-5 members?

-Bertrand

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

Re: pTLP, concretely

On Mon, Jan 5, 2015 at 3:15 PM, Benson Margulies bimargul...@gmail.com wrote:
 ...This scheme locates
 that responsibility in the renamed committee, which serves the board
 by supervising the pTLPs. They aren't mentors, they are PMC members...

Ok, but the board needs to accept those folks, and the incoming pTLP
needs to locate 4-5 such folks that the board will accept. I bet that
would result in smaller potential projects just fading away, which
goes against our inclusive principles.

-Bertrand

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

Re: pTLP, concretely

On Mon, Jan 5, 2015 at 9:25 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Mon, Jan 5, 2015 at 3:15 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 ...This scheme locates
 that responsibility in the renamed committee, which serves the board
 by supervising the pTLPs. They aren't mentors, they are PMC members...

 Ok, but the board needs to accept those folks, and the incoming pTLP
 needs to locate 4-5 such folks that the board will accept. I bet that
 would result in smaller potential projects just fading away, which
 goes against our inclusive principles.

I agree. It painfully obvious (to me) that we don't have enough
qualified mentors to handle all the small projects that want to show
up. In my view, any move in any direction has to confront this.




 -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: pTLP, concretely


On Jan 5, 2015, at 6:15 AM, Benson Margulies bimargul...@gmail.com wrote:

 On Mon, Jan 5, 2015 at 8:41 AM, Alan Cabrera l...@toolazydogs.com wrote:
 
 
 On Jan 5, 2015, at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org 
 wrote:
 
 On Jan 5, 2015, at 4:20 AM, Benson Margulies bimargul...@gmail.com 
 wrote:
 
 For your reading and wrangling pleasure, I offer:
 https://wiki.apache.org/incubator/IncubatorV2. ...
 
 IIUC the main difference (besides subtle naming changes) is that pTLPs
 vote on their own releases, based on pTLP PMC members who have been
 accepted by the board?
 
 So more work for the board, and each pTLP needs to form an acceptable
 PMC roster with at least 4-5 members?
 
 My thoughts exactly. What this proposal effectively does is pawn off the 
 responsibility of holding mentors accountable to the board.
 
 No. The original uncooked pTLP scheme did that. This scheme locates
 that responsibility in the renamed committee, which serves the board
 by supervising the pTLPs. They aren't mentors, they are PMC members.

A rose by any other name?


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

Re: Incubator report sign-off

On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:

1. get rid of IPMC altogether and move to the pTLP model

 This is effectively an IPMC reboot.  I don’t really see anything 
 substantially different.

At this point, I'm convinced this is the only fruitful path forward,
the rest is a shell game with responsibility. See the other thread.

3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
   deteriorate into mindless tick-offs -- but at least it does not harm).

 How is it that a mentor became an IPMC member and do such an unethical thing 
 such as a mindless tick-off?

We're talking about human being here. The one who never
ever cut corners in his life can cast the first stone.

Thanks,
Roman.

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

Re: pTLP, concretely

On Mon, Jan 5, 2015 at 11:11 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Jan 5, 2015, at 7:04 AM, Benson Margulies bimargul...@gmail.com wrote:

 On Mon, Jan 5, 2015 at 9:25 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Mon, Jan 5, 2015 at 3:15 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 ...This scheme locates
 that responsibility in the renamed committee, which serves the board
 by supervising the pTLPs. They aren't mentors, they are PMC members...

 Ok, but the board needs to accept those folks, and the incoming pTLP
 needs to locate 4-5 such folks that the board will accept. I bet that
 would result in smaller potential projects just fading away, which
 goes against our inclusive principles.

 I agree. It painfully obvious (to me) that we don't have enough
 qualified mentors to handle all the small projects that want to show
 up. In my view, any move in any direction has to confront this.

 This, imo, is the crux of the problem.  This proposal does not focus on this 
 issue other than to rename the roll.

Last comment from me for today:

to me, PMC membership, and especially PMC chairship, is a big deal. If
you accept it, you accept real responsibility, with real potential
legal consequences to the Foundation if you screw it up. There's
nothing like that about being a mentor. Legally, today, responsibility
for podlings sits with the IPMC chair and the IPMC members,
collectively, not with the particular mentors in particular of the
particular project,. So, again, to me, the pTLP scheme is very
different from the current scheme. It seems that other people don't
see this the same way that I do. If the general feeling is that PMC
membership is 'a joke' like mentorship is 'a joke', then this scheme
of mine is just more standup comedy.

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

Re: [DISCUSS] Rolling shepherds?


On Dec 9, 2014, at 6:30 PM, John D. Ament johndam...@apache.org wrote:

 The following shepherds either did not provide, or did provide but saw no
 issues to comment on within their podlings:
 
 - Alan Cabrera

I am committed to reviewing the podlings for which I am a mentor.  For other 
podlings, not so much.  When I am a shepherd and I have time to review a 
podling, I will.  Often, I do not have that time.

If this criteria is inadequate for me being a shepherd then feel free to remove 
me from the rotating list.


Regards,
Alan

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Mon, Jan 5, 2015 at 9:14 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 As for measuring the mentors activity, I suggest simply adding a
 question to the podling reports, who are your two active mentors and
 are you happy with their activity along with requiring report
 sign-off from those two mentors.

This is basically what I proposed a few months back when we
were talking about 360-degree feedback being incorporated
into the Incubator report. Last time this idea was +0ish at best.

The tracking part is easy, though. What's difficult is the part
that would require us to do something with poddlings put
on hold. Unless we come up with clear exit criteria for
this new state -- I don't think we're solving any real problems
here.

Thanks,
Roman.

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

Request for ContributorsGroup access for updating Incubator project status

2015-01-05 Thread Selvamohan Neethiraj

I am trying to update the Apache Ranger (incubating) project status in the 
Wiki. 

Can someone add my wiki user account (Selvamohan Neethiraj) to 
ContributorsGroup for me to be able to edit the Apache Incubator Wiki ? 


Thanks,
Selva-


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Mattmann, Chris A (3980)

Guys,

Podlings are already in charge of their mentors. They recruit them
(actively, even before Incubation) and I’ve never seen a podling
with mentors “forced” on to them.

What new thing is being proposed here?

Cheers,
Chris




-Original Message-
From: Bertrand Delacretaz bdelacre...@apache.org
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Monday, January 5, 2015 at 9:14 AM
To: Incubator General general@incubator.apache.org
Subject: Podlings should be in charge of their mentors (was: Incubator
report sign-off)

Hi,

I'm resending Alan's proposal with a new subject as I think it
deserves more attention.

On Mon, Jan 5, 2015 at 1:57 PM, Alan D. Cabrera l...@toolazydogs.com
wrote:
 ...Podlings would be required to have a minimum of two active mentors.
A mentor is free to become inactive
 but must explicitly state this else the mentor risks being removed for
not performing their duties.  Podlings that
 do not have the minimum of two active mentors are put on hold until
they find enough mentors to fill the quota.
 Being put on hold means that no committers can be added, no PPMC
members can be added, and no
 releases can be performed.  It does not stop development...

I like it very much...it's a small, reversible step that puts the
burden on podlings and mentors, which are the ones who should be
concerned about podlings going forward.

It's also consistent with podlings having to find mentors to join the
Incubator - they just have to keep on making sure their mentors are
active, or ask for new ones when needed.

As for measuring the mentors activity, I suggest simply adding a
question to the podling reports, who are your two active mentors and
are you happy with their activity along with requiring report
sign-off from those two mentors.

-Bertrand

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

Re: pTLP, concretely

On Mon, Jan 5, 2015 at 8:24 AM, Benson Margulies bimargul...@gmail.com
wrote:

 Last comment from me for today:

Thanks very much for continuing to exercise discipline in rate-limiting your
communiques, Benson.  I dread the prospect of returning to the overheating,
rapid-fire IPMC of a few years ago.

 to me, PMC membership, and especially PMC chairship, is a big deal. If you
 accept it, you accept real responsibility, with real potential legal
 consequences to the Foundation if you screw it up. There's nothing like that
 about being a mentor. Legally, today, responsibility for podlings sits with
 the IPMC chair and the IPMC members, collectively, not with the particular
 mentors in particular of the particular project,. So, again, to me, the pTLP
 scheme is very different from the current scheme. It seems that other people
 don't see this the same way that I do. If the general feeling is that PMC
 membership is 'a joke' like mentorship is 'a joke', then this scheme of mine
 is just more standup comedy.

The problem is that exercising that level of responsibility as a PMC member is
optional.  Some people take it that seriously, and those individuals anchor
our projects -- but we have also found that keeping the bar for PMC membership
low and offering people a governance stake earlier rather than later has
beneficial effects in terms of inclusiveness and motivating contributors.

Currently, the Incubator treats Mentorship the same way: the more the merrier,
contribute what you can, merit basically never expires.  But it doesn't have
to be that way.  We can require ongoing activity for Mentors and remove those
who become inactive.  We can limit the maximum number of Mentors, perhaps
returning to having only a single Mentor per podling.

In fact, I'd say that treating Mentorship differently than PMC membership will
be key to addressing the Incubator's structural incentive difficulties.

Marvin Humphrey

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Rich Bowen




On 01/05/2015 12:14 PM, Bertrand Delacretaz wrote:

  A mentor is free to become inactive

but must explicitly state this else the mentor risks being removed for not 
performing their duties.


For most mentors, it seems that going inactive is a gradual slide, not a 
momentous decision.


--
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Re: Incubator report sign-off


On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
   1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I don’t really see anything 
 substantially different.
 
 At this point, I'm convinced this is the only fruitful path forward,
 the rest is a shell game with responsibility. See the other thread.
 
   3. patch the current process with starting to drop the mentors from
   the project who don't sign off. This will essentially serve
   as a heartbeat for mentors (now, in my opinion it'll quickly
  deteriorate into mindless tick-offs -- but at least it does not harm).
 
 How is it that a mentor became an IPMC member and do such an unethical thing 
 such as a mindless tick-off?
 
 We're talking about human being here. The one who never
 ever cut corners in his life can cast the first stone.

I think that you misunderstood my rhetorical question.  It is my 
experience/understanding that if a mentor makes an effort to review 
reports/releases then this mentor is actually doing a good job at it.  It is my 
experience/understanding that the overwhelming problem is that mentors simply 
go MIA and do nothing at all.

I am in favor of #3 since it holds mentors accountable.  #1 is simply a washing 
of our hands and pawning the problem off on the board simple because some of us 
are unwilling to do uncomfortable things.


Regards,
Alan






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

Podlings should be in charge of their mentors (was: Incubator report sign-off)

Hi,

I'm resending Alan's proposal with a new subject as I think it
deserves more attention.

On Mon, Jan 5, 2015 at 1:57 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 ...Podlings would be required to have a minimum of two active mentors.  A 
 mentor is free to become inactive
 but must explicitly state this else the mentor risks being removed for not 
 performing their duties.  Podlings that
 do not have the minimum of two active mentors are put on hold until they find 
 enough mentors to fill the quota.
 Being put on hold means that no committers can be added, no PPMC members can 
 be added, and no
 releases can be performed.  It does not stop development...

I like it very much...it's a small, reversible step that puts the
burden on podlings and mentors, which are the ones who should be
concerned about podlings going forward.

It's also consistent with podlings having to find mentors to join the
Incubator - they just have to keep on making sure their mentors are
active, or ask for new ones when needed.

As for measuring the mentors activity, I suggest simply adding a
question to the podling reports, who are your two active mentors and
are you happy with their activity along with requiring report
sign-off from those two mentors.

-Bertrand

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

Re: Incubator report sign-off

On Mon, Jan 5, 2015 at 8:59 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 I am in favor of #3 since it holds mentors accountable.  #1 is simply a 
 washing of
 our hands and pawning the problem off on the board simple because some of us
 are unwilling to do uncomfortable things.

Here's the bit that seems to be misunderstood a lot in pTLP discussion: the
appealing part of that proposal is making mentors part of *real* PMCs of
*real* projects, as opposed to being beholden to a vague committee (IPMC).
In my (and a few others) opinion, this is the only structuring of incentive
that would make a needle on mentors being there *for real*. At least as
real as all the other PMCs of TLPs (which should be as good as it gets
at ASF).

That said, lets argue this in a thread where it belongs (the one started
by Benson).

Thanks,
Roman.

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Mon, Jan 5, 2015 at 6:21 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here

A podling that's on hold is not adding committers nor making releases,
so they cannot make progress towards graduation.

They can then be managed in the same way as non-progressing podlings:
fail them if that state persists for too long. That's a minimal change
from how we're operating now.

-Bertrand

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

Re: Reflections from the outgoing Chair


On Dec 31, 2014, at 5:26 PM, Roman Shaposhnik r...@apache.org wrote:

 when a honor of the IPMC chair was bestowed on
 me beginning of 2014 it was crucial  that the
 position remains to be rotated among IPMC members.
 As an aside: while Marvin felt that the ideal rotation period
 was 6 month my personal belief was that 12 months
 makes it long enough to be able to accomplish something,
 while short enough to still accomplish the goals of a
 rotating chair.

Thank you for your awesome term of service!


Regards,
Alan

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Mon, Jan 5, 2015 at 6:27 PM, Mattmann, Chris A (3980)
chris.a.mattm...@jpl.nasa.gov wrote:
 What new thing is being proposed here?...

This, meant to fix the mentors fade away problem:

...Podlings that
 do not have the minimum of two active mentors are put on hold until
they find enough mentors to fill the quota

-Bertrand

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

Re: Incubator report sign-off

2015-01-05 Thread Mattmann, Chris A (3980)

It’s not a pawning off to the board - the board is already
responsible for reviewing the IPMC report which includes
*all of the same detail* that the IPMC also .. reviews.

Cheers,
Chris



-Original Message-
From: Alan D. Cabrera l...@toolazydogs.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Monday, January 5, 2015 at 8:59 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator report sign-off


On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
   1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I don’t really see anything
substantially different.
 
 At this point, I'm convinced this is the only fruitful path forward,
 the rest is a shell game with responsibility. See the other thread.
 
   3. patch the current process with starting to drop the mentors from
   the project who don't sign off. This will essentially serve
   as a heartbeat for mentors (now, in my opinion it'll quickly
  deteriorate into mindless tick-offs -- but at least it does not
harm).
 
 How is it that a mentor became an IPMC member and do such an unethical
thing such as a mindless tick-off?
 
 We're talking about human being here. The one who never
 ever cut corners in his life can cast the first stone.

I think that you misunderstood my rhetorical question.  It is my
experience/understanding that if a mentor makes an effort to review
reports/releases then this mentor is actually doing a good job at it.  It
is my experience/understanding that the overwhelming problem is that
mentors simply go MIA and do nothing at all.

I am in favor of #3 since it holds mentors accountable.  #1 is simply a
washing of our hands and pawning the problem off on the board simple
because some of us are unwilling to do uncomfortable things.


Regards,
Alan






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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Monday, January 5, 2015, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 Hi,

 I'm resending Alan's proposal with a new subject as I think it
 deserves more attention.

 On Mon, Jan 5, 2015 at 1:57 PM, Alan D. Cabrera l...@toolazydogs.com
 javascript:; wrote:
  ...Podlings would be required to have a minimum of two active mentors.
 A mentor is free to become inactive
  but must explicitly state this else the mentor risks being removed for
 not performing their duties.  Podlings that
  do not have the minimum of two active mentors are put on hold until they
 find enough mentors to fill the quota.
  Being put on hold means that no committers can be added, no PPMC members
 can be added, and no
  releases can be performed.  It does not stop development...

 I like it very much...it's a small, reversible step that puts the
 burden on podlings and mentors, which are the ones who should be
 concerned about podlings going forward.

 It's also consistent with podlings having to find mentors to join the
 Incubator - they just have to keep on making sure their mentors are
 active, or ask for new ones when needed.


 As for measuring the mentors activity, I suggest simply adding a
 question to the podling reports, who are your two active mentors and
 are you happy with their activity along with requiring report
 sign-off from those two mentors.


I like this idea, except putting the full responsibility of finding new
mentors on the shoulders of the podling. Asking for mentors is easy getting
a response seems to be difficult for the smaller projects. Don't forget we
voted and accepted the podling, so we have at least part of the
responsibility for making mentors available

I am very much afraid it will endanger our smaller less popular projects.
In order to stay safe this requires at least 3 mentors at all times in
order not to block the podling...3 mentors are surely ok for bigger
project, but a bit overkill for small ones.

Maybe we should relate the number of mentors to the size of the community
instead of a fixed number.

just my thoughts.
jan i


 -Bertrand

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



-- 
Sent from My iPad, sorry for any misspellings.

Re: Reflections from the outgoing Chair

Hi!

I think this thread has achieved its goal and the real discussion
is now happening on the thread re: Benson's proposal. I couldn't
have asked for more -- lets move the real discussion over there.
Before we do that, however, I wanted to make a few quick remarks.

First of all, I really appreciate the positive feedback on my tenure
expressed on this thread. All I can say is: I tried my best and I couldn't
have survived as long as I did without lots of support from my
dear colleagues and mentors. Thank you!

Re: Upayavira's point on release auditing. I believe this has been
adequately answered and incorporated into Benson's proposal.

Re:
||| It is my impression that no one is very happy with the current state
||| of the incubation process. On the other hand, I'm sure, from extensive
||| personal experience, that the IPMC's size is a serious impediment to
||| addressing its issues. It's just very, very, hard to reach consensus
||| at this scale.
[...]
||| My proposal is to form a select committee.

Huge +1 to the idea. Benson, since you proposed it, could you please
fork it off into a separate thread?

With that: lets the rest of this discussion be conducted around the
concrete proposal brought forth by Benson. At this point, I really
hope we can make progress there and bring a real plan to the
attention of the board soon.

This thread is now officially closed ;-)

Thanks,
Roman.

On Wed, Dec 31, 2014 at 5:26 PM, Roman Shaposhnik r...@apache.org wrote:
 Hi!

 when a honor of the IPMC chair was bestowed on
 me beginning of 2014 it was crucial  that the
 position remains to be rotated among IPMC members.
 As an aside: while Marvin felt that the ideal rotation period
 was 6 month my personal belief was that 12 months
 makes it long enough to be able to accomplish something,
 while short enough to still accomplish the goals of a
 rotating chair.

 At any rate, with my 12 months almost up, it makes the last
 day of the year a perfect  cut-off point to start talking about
 transition the Chair position, if it wasn't for one issue:

 At this point I'm really convinced that what ASF needs is
 not the next IPMC Chair, but the *last* IPMC Chair. That
 is to say, I truly feel like the best outcome for everybody
 involved in Incubation process is if by the end of 2015 IPMC
 gets completely dissolved. Here's why:

 First of all, as was pointed out in two other threads by Chris
 and Benson (see the quotes bellow) the current process lacks
 the most crucial bit of what Incubation is supposed to be all
 about: Apache project on training wheels.  Instead of teaching
 our podlings what it really feels to have a responsible PMC
 and a Chair skilled in the Apache Way dealing with the board,
 we have IPMC.

 After serving in my current position for almost a year, I'm fully
 convinced by now, that there's a very fundamental problem
 with the organization. The existence of IPMC (despite all
 the goodness that still comes from it) has become a too-convenient
 of a excuse for *everybody* to play a really nasty shell game with
 responsibility.

 While the situation with ASF TLPs varies, at least the system
 is setup in such a way that there's a very clear accountability
 What's more important, there's a vested interest from those with
 authority (PMC, PMC Chair and the Board) to make sure the
 project is doing the right thing. Presumably, if you're on PMC
 of a TLP you really don't want the PMC to be dissolved and
 the project go away. You're not a member of some ethereal
 league of extraordinary gentlemen (aka IPMC) your status
 is in direct relationship to the livelihood of your project. Without
 the project there's no status, which is exactly *not* the case
 with IPMC. A pretty powerful motivator for doing the right thing
 is clearly lacking.

 Now, one might say that we don't need to dissolve the IPMC
 in order to fix this, one might say that something along the
 lines of original Ross' proposal would do. I would disagree. I think
 that the only way to send the message or clear responsibility
 is to make it impossible to be associated with an incubating
 project in any other way, but being on its PMC. You're either
 in or out. There's no other place to boost your ASF karma
 (which, sadly, I've seen around IPMC more than I'd like to).

 But wait, there's more! This real assignment of responsibility
 wouldn't just happen at the mentor level, it'll extend all the
 way to the board. The board will be directly engaged in
 overseeing the incubating projects and that direct interaction
 will be as much a part of the Incubation experience as
 producing releases or growing the community. The scalability
 of the board is not an issue here. First of all, the board still
 needs to read all the Incubating reports and moreover
 if the board doesn't feel scalable enough today, why would
 all of a sudden scale if all the projects vote on graduation
 at once tomorrow (and pass!)? If nothing else, this real
 engagement gives the board a very

RE: Binary Convenience Package Dependencies

2015-01-05 Thread Dennis E. Hamilton

The answers below are not on behalf of the ASF, but based on what the
common sense appears to be, from my individual perspective.

In particular, your project is not relieved from learning what a license
requires of it and demonstrating satisfaction of such requirements.

 -- replying below to --
From: Alex Harui [mailto:aha...@adobe.com] 
Sent: Monday, January 5, 2015 09:52
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies

[ ... ]
2A) If your build script downloads an MPL jar, must it provide an option
to download the source?

2B) If your build script downloads an MPL jar, is any other additional
warning or explicit action required?

orcmid
   It depends on what the governing license requires with respect to 
   Whatever is being done with the download.  If you are redistributing
   the jar or anything in it, see (2C).

   As a *practice* it can be valuable to download accompanying licenses
   and to make it clear where the download is obtained.  That's a matter
   of being transparent with regard to the provenance of code being used
   and what version it is, etc.  That can matter in the event there is a
   later concern about revelations of upstream defects, vulnerabilities,
   and such.

   Presumably the upstream source will provide any determination on the
   availability of source code.  (In (2B) there is no indication that the
   ASF project is accessing such source code itself.)
/orcmid

2C) If your binary package bundles an MPL jar (assuming the answer to #1
allows it), must it provide an option to download the source?

orcmid
   This item has nothing to do with the ASF policy about category B software.
   For (2C), the obligation is to comply with the MPL license with respect
   to redistribution of a binary component that is provided under that 
   license.  
  In particular, what other ASF projects might or might not do is not a
   reliable precedent for what your project does.  What your project must
   do is comply with the applicable license.  There may be additional steps
   required as part of the ASF policy and recommendations, but the minimum
   is determined by the governing license.
  For example, your project's LICENSE and NOTICE files included in your
   binary package bundle will likely also address the presence of the 
   MPL-licensed dependency, as required in accordance with ASF policy.
/orcmid

Thanks,
-Alex

[1] http://www.apache.org/dev/release.html
[2] http://www.apache.org/legal/resolved.html

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

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

Re: Incubator report sign-off

On Mon, Jan 5, 2015 at 1:07 PM, Ross Gardler (MS OPEN TECH)
ross.gard...@microsoft.com wrote:
 But the board is not responsible for any actions resulting from those 
 reviews, the IPMC is.

Agreed for the state of the things today. What is being proposed
is that actions resulting from those reviews are going to be
pTLPs PMC responsibility. Since in the new world order each
pTLP PMC is guaranteed to have 3 ASF members and a chair
(one of the 3) that is also an ASF member, I don't think I can
see how this would be disagreeable with the mechanics
of ASF board.

Thanks,
Roman.

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

Request edit karma for wiki

For some reason HadrianZbarcea can no longer edit the wiki. Could 
somebody please grant me access. Please verify the @a.o address for the 
account.


Thanks,
Hadrian


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

RE: Incubator report sign-off

As I've said repeatedly. This simply moves the problem it does not solve it. 
Today, a project has mentors, usually it works, but sometimes it doesn't. When 
it doesn't work someone needs to fix it. That is the work that is being moved 
from the IPMC to the board by the pTLP proposal.

It's not necessarily a bad thing and may be acceptable to the board, but I 
don't understand why proponents of this approach feel it is a solution rather 
than a moving of the problem.

Furthermore, I've not even started on who would own the documentation aspect 
(yes the proposal is ComDev but just as last time this was circulated nobody 
has asked ComDev if they are willing to take it on and nobody has turned up in 
ComDev to do the work.

This proposal is not necessarily flawed, but it is incomplete.

Ross


-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, January 5, 2015 1:52 PM
To: general@incubator.apache.org
Subject: Re: Incubator report sign-off

On Mon, Jan 5, 2015 at 1:07 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:
 But the board is not responsible for any actions resulting from those 
 reviews, the IPMC is.

Agreed for the state of the things today. What is being proposed is that 
actions resulting from those reviews are going to be pTLPs PMC responsibility. 
Since in the new world order each pTLP PMC is guaranteed to have 3 ASF members 
and a chair (one of the 3) that is also an ASF member, I don't think I can see 
how this would be disagreeable with the mechanics of ASF board.

Thanks,
Roman.

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

Re: Binary Convenience Package Dependencies

2015-01-05 Thread Andrea Pescetti


On 05/01/2015 jan i wrote:

On 5 January 2015 at 18:52, Alex Harui wrote:

2) In [2] it says for Category B: By including only the object/binary
form, there is less exposed surface area of the third-party work from
which a work might be derived; this addresses the second guiding principle
of this policy. By attaching a prominent label to the distribution and
requiring an explicit action by the user to get the reciprocally-licensed
source, users are less likely to be unaware of restrictions significantly
different from those of the Apache License.”  Does “including” means
“bundling”?  If so, the quoted text must be referencing binary packages
and not source packages since source packages can never include
object/binary forms.  Or does “including” also refer to build scripts that
download an MPL jar like Saxon?


AOO release notes, includes the list of external packages (binary) we use,
but we do NOT provide the source for these libraries, nor do our installer
give the user a possibility to download.


Let me just complete this. The OpenOffice SVN repository (but, Jan is 
correct, not the source package we ship) does include some libraries 
that are under Category A. OpenOffice can be fully built from that 
source package, but our users need additional functionality.


So the convenience binaries are configured with --enable-category-b 
(yes, we really have a configure option named that way) and include 
binary forms of some extra libraries. These are listed and credited not 
in the Release Notes, but in the LICENSE file. So credits and notices 
are shipped with the binaries.


Again, for convenience of developers, we archive the Category A 
materials in SVN, and we archive Category B materials on Apache Extras, 
which seemed a wonderful idea to have them permanently archived until 
Google decided to pull the plug and shut down Apache Extras...


Regards,
  Andrea.

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

Back in 2013, I suggested asking the Champion to accept a very clear
level of reporting responsibility: to write a sentence or two _every
month_ or find someone else to do it. That's one person whom I wanted
to ask to sign up, for the duration of an incubation, to pay enough
attention to be able to report a basic heartbeat.

?


On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote:


 On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:
 On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:

 
  On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
 
   On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
   javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
  
  
   On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
  wrote:
  
   The tracking part is easy, though. What's difficult is the part
   that would require us to do something with poddlings put
   on hold. Unless we come up with clear exit criteria for
   this new state -- I don't think we're solving any real problems
   here.
  
   There’s no silver bullet here, if a podling cannot whip up a mentor it’s
   because:
   the podling is not popular and should probably be retired anyway, being
   put on hold will provide impetus for the podling to seek out a new venue
   there are not enough mentors
   There is no way to magically solve the latter.
  
  
   You mean popular within the pool of mentors (IPMC), the project can still
   be popular on several other scales.
 
  I’m not speaking of popularity of mentors; I regret that choice of words.
  I am stating that active and healthy podlings seem to have no trouble
  attracting active mentors.
 
  The converse seems to be true.  Unhealthy podlings seem to attract mentors
  who have signed up out of pity and subsequently go MIA.
 
 I agree with the last part, I still have to see mentors volunteer for
 small
 active and healthy projects which might not be main road. Of course it
 depends on how active and healthy is defined, but as an example my little
 project Corinthia barely managed to get 2 mentors, while in the same time
 span we got 3 committers.

 
  Before anyone replies, I understand this is not a hard and fast rule but
  an imperfect qualitative observation on my part.
 
  Anyway, active and responsible mentors will eventually get to all podlings.
 
   I might lack experience, but why do more active mentors guarantee that
  the
   podling will be a better TLP ?
 
  I’m not sure who’s making that assertion.
 
 Well its because I cannot see why a podling need more than 1 active
 mentor
 at all timeshaving multiple is fine, to cover each other, but it
 should
 not take more than 1 mentor to learn a podling, what it needs to
 understand. The suggestion implicit says 2 mentors is the minimum needed
 for at podling to become a successful TLP.


 
   We try to solve the problem of mentors not being active but adding more
   volume. I don't believe that is the right cure.
 
  We’re not adding volume.  The volume is already there.  We’re just making
  the state of affairs more explicit and transparent and adding culpability
  for MIA mentors.
 
 Do we have a rule today that a podling needs at least 2 active mentors
 (if
 we have that, then we would not have a problem with sign offs, or a lot
 of
 dead podlings), at least I have not seen itthat is what I mean by
 adding volume.

 If just 1 mentor is active and sign off the reports, then I do not see
 the
 problem.



 
   I do agree with bernard that it is the podling that should ask for
   helpbut the IPMC should solve it.,
 
  Yes, it should help solve problems but if there are no mentors available
  there are no mentors available.
 
 Then the IPMC should not have accepted the podling in the first place!

 It is simply not fair to make the life of a podling, depending on whether
 or not we have mentors available (REMARK after accepting the proposal) !
 If
 the podling have a healthy community and are active, we cannot and should
 not close it down, just because we have a mentor problem.

 To me telling a podling it cannot grow its community nor make releases,
 is
 the same as closing it down.

 Jan,

 From an idealistic perspective, you are completely right. Apache should,
 once a project has been accepted, provide the support needed.

 The reality is that, given the ASF's volunteer nature, that simply won't
 always work.

 I'd much rather we be clear with projects right up front, saying
 something like:

 To join the Incubator, you need one or more mentors. To get to
 graduation, you will need the support of those mentors. If mentors
 become unavailable, you will need to seek replacements. Unless you have
 already learned the ways of the ASF and are ready to graduate, you will
 need to keep engaged with your mentors. If possible, engage in the wider
 ASF, and develop connections with others who might be in a position to
 assist with mentorship should one or all of your

Re: Request for ContributorsGroup access for updating Incubator project status

On Mon, Jan 5, 2015 at 9:23 AM, Selvamohan Neethiraj
sneet...@apache.org wrote:

 Can someone add my wiki user account (Selvamohan Neethiraj)

Done.

(Wiki ID includes space.)

Marvin Humphrey

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

Re: Request edit karma for wiki

On Mon, Jan 5, 2015 at 3:32 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:
 For some reason HadrianZbarcea can no longer edit the wiki. Could somebody
 please grant me access.

That wiki ID wasn't listed in ContributorsGroup, nor in
Administrators.  I've added it to ContributorsGroup.

 Please verify the @a.o address for the account.

I'm not sure how to do that.  So long as you can log in, though, I
believe adding you to ContributorsGroup suffices and no further action
is necessary.  Even logged in, you would not have been able to edit
the wiki before; you should be able to now.

Cheers,

Marvin Humphrey

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

Re: Incubator report sign-off

2015-01-05 Thread Andrew Purtell

 One extra thing to note, that while we can *start* this comittee as
dedicated
 
to Incubating projects, it will be a very natural extension to get it
involved
 
in monitoring all of TLPs, not just pTLPs.

What problem exists today where the Board needs
such 
a buffer?

In what ways could this committee substitute its judgement for PMC of the
TLP?

How would one apply to be on this committee? Would this be a case of some
members being more member than others?

What would be the process and expectations for resolving disagreements
between the TLP and this committee?  



On Mon, Jan 5, 2015 at 3:38 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 I am clearly hitting my rate-limit with emails to general@, still since
 Ross' reply was one of the few pieces of feedback from the board,
 I'll do this one and then wait for others to chime in (Benson?).

 On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
  This proposal is not necessarily flawed, but it is incomplete.

 Couldn't agree more. But! The whole point is to try our best
 to get this:
 https://wiki.apache.org/incubator/IncubatorV2
 to completion. Your direct feedback (as a sort of proxy for the
 board) is *very* much appreciated.

  As I've said repeatedly. This simply moves the problem it does
  not solve it. Today, a project has mentors, usually it works,
  but sometimes it doesn't. When it doesn't work someone needs
  to fix it. That is the work that is being moved from the IPMC to
  the board by the pTLP proposal.

 Benson, perhaps we need to create an FAQ around failure scenarios
 on your wiki page. Here's what I would say to address the failure
 scenario described by Ross.

 An addition of the overseeing committee, will shield the board from
 *some* of the day-to-day business of telling the pTLP that something
 needs to be fixed. So lets, break the cases down:
1. pTLP is *really* doing fine, which means:
 1.1. overseeing committee has nothing to address
 1.2. board *still* has to review the reports (as it does today)
and agrees with the overseeing committee
END RESULT: no additional work for the board

2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee:
 2.1. board expresses its concerns *directly* to the pTLP PMC
while CCing the committee essentially pointing out something
 that
fell through the cracks when it should NOT have. NOTE: a huge
difference here is that board does NOT expect a committee to
fix the issue, but rather makes it aware of something that
 should've
been flagged by it. Only pTLP PMC can act to remedy the issue,
nobody else can help them (they could, of course, request help,
but again -- it has to come from them
 2.2. pTLP PMC either fixes the issue. The comittee and the board
 are
happy again
 2.3. pTLP PMC doesn't fix the issue == GOTO #3 (we are expecting
the level of maturity and dedication from the committee members
 so
that GOTO #2 becomes impossible since the board explicitly
 flagged
this issue in 2.1)
END RESULT: no additional work for the board

3. pTLP is NOT doing fine and it gets flagged by the committee, which
 means:
 3.1. since committee is treated as an extension of the board,
 its authority
 and the gravity of its opinion have exactly the same
 consequences if
 the board flagged it (we may need to come up with
 additional steps for
 the board to vet the committee's opinion, though)
 3.2. the committee STILL is not responsible for fixing the
 problem, the PMC is.
END RESULT: no additional work for the board

 Essentially, the overseeing committee acts as an extension of
 the board, but the ultimate responsibility lies with pTLP PMCs.
 In that sense the overseeing committee inherits the good and
 the bad sides of the board. More specifically:
 1. it becomes a jackhammer, not a scalpel
 2. it is NOT expected to fix the problem, but rather unearth it
 and delegate the solution to the PMC
 3. if PMC doesn't act *really* grave consequences could follow
 4. the level of maturity and the size of the committee needs to be
 as close to the board's level as possible. That is the part that is
 nicely addressed in Benson's wiki.

 Here's an elevator pitch: when it comes to running the foundation
 according to the 'Apache Way', the committee is a vice-board.

 One extra thing to note, that while we can *start* this comittee as
 dedicated
 to Incubating projects, it will be a very natural extension to get it
 involved
 in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea
 couldn't
 have been timelier.

 Honestly, I really feel we've collectively stumbled on something really
 promising here.

  It's not necessarily a bad thing and may be

Re: Incubator report sign-off

I am clearly hitting my rate-limit with emails to general@, still since
Ross' reply was one of the few pieces of feedback from the board,
I'll do this one and then wait for others to chime in (Benson?).

On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH)
ross.gard...@microsoft.com wrote:
 This proposal is not necessarily flawed, but it is incomplete.

Couldn't agree more. But! The whole point is to try our best
to get this:
https://wiki.apache.org/incubator/IncubatorV2
to completion. Your direct feedback (as a sort of proxy for the
board) is *very* much appreciated.

 As I've said repeatedly. This simply moves the problem it does
 not solve it. Today, a project has mentors, usually it works,
 but sometimes it doesn't. When it doesn't work someone needs
 to fix it. That is the work that is being moved from the IPMC to
 the board by the pTLP proposal.

Benson, perhaps we need to create an FAQ around failure scenarios
on your wiki page. Here's what I would say to address the failure
scenario described by Ross.

An addition of the overseeing committee, will shield the board from
*some* of the day-to-day business of telling the pTLP that something
needs to be fixed. So lets, break the cases down:
   1. pTLP is *really* doing fine, which means:
1.1. overseeing committee has nothing to address
1.2. board *still* has to review the reports (as it does today)
   and agrees with the overseeing committee
   END RESULT: no additional work for the board

   2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee:
2.1. board expresses its concerns *directly* to the pTLP PMC
   while CCing the committee essentially pointing out something that
   fell through the cracks when it should NOT have. NOTE: a huge
   difference here is that board does NOT expect a committee to
   fix the issue, but rather makes it aware of something that should've
   been flagged by it. Only pTLP PMC can act to remedy the issue,
   nobody else can help them (they could, of course, request help,
   but again -- it has to come from them
2.2. pTLP PMC either fixes the issue. The comittee and the board are
   happy again
2.3. pTLP PMC doesn't fix the issue == GOTO #3 (we are expecting
   the level of maturity and dedication from the committee members so
   that GOTO #2 becomes impossible since the board explicitly flagged
   this issue in 2.1)
   END RESULT: no additional work for the board

   3. pTLP is NOT doing fine and it gets flagged by the committee, which means:
3.1. since committee is treated as an extension of the board,
its authority
and the gravity of its opinion have exactly the same consequences if
the board flagged it (we may need to come up with
additional steps for
the board to vet the committee's opinion, though)
3.2. the committee STILL is not responsible for fixing the
problem, the PMC is.
   END RESULT: no additional work for the board

Essentially, the overseeing committee acts as an extension of
the board, but the ultimate responsibility lies with pTLP PMCs.
In that sense the overseeing committee inherits the good and
the bad sides of the board. More specifically:
1. it becomes a jackhammer, not a scalpel
2. it is NOT expected to fix the problem, but rather unearth it
and delegate the solution to the PMC
3. if PMC doesn't act *really* grave consequences could follow
4. the level of maturity and the size of the committee needs to be
as close to the board's level as possible. That is the part that is
nicely addressed in Benson's wiki.

Here's an elevator pitch: when it comes to running the foundation
according to the 'Apache Way', the committee is a vice-board.

One extra thing to note, that while we can *start* this comittee as dedicated
to Incubating projects, it will be a very natural extension to get it involved
in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea couldn't
have been timelier.

Honestly, I really feel we've collectively stumbled on something really
promising here.

 It's not necessarily a bad thing and may be acceptable to the board,
 but I don't understand why proponents of this approach feel it is a
 solution rather than a moving of the problem.

Benson, another useful section on the wiki could be explicit listing
of the benefits of the proposal. Here's what I see as benefits:
   1. the new scheme avoids a very dangerous delusion that
IPMC somehow can 'fix' problems. In the new scheme that
is clearly not the case -- only PMC can fix problems (or perish!).
This is very much in-line with how TLPs are setup.

2. it avoids a very dangerous idea of IPMC having
a 'collective responsibility' for projects (and we all know if
everybody is responsible -- nobody really is). In the new scheme,
the only place responsible for

RE: Incubator report sign-off

Note from the board - from an IPMC member (and yes, my opinions don't change if 
I put my Director hat on but don't assume that I speak for all board members)

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, January 5, 2015 3:39 PM
To: general@incubator.apache.org; Benson Margulies
Subject: Re: Incubator report sign-off

I am clearly hitting my rate-limit with emails to general@, still since Ross' 
reply was one of the few pieces of feedback from the board, I'll do this one 
and then wait for others to chime in (Benson?).

On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:
 This proposal is not necessarily flawed, but it is incomplete.

Couldn't agree more. But! The whole point is to try our best to get this:
https://wiki.apache.org/incubator/IncubatorV2
to completion. Your direct feedback (as a sort of proxy for the
board) is *very* much appreciated.

 As I've said repeatedly. This simply moves the problem it does not 
 solve it. Today, a project has mentors, usually it works, but 
 sometimes it doesn't. When it doesn't work someone needs to fix it. 
 That is the work that is being moved from the IPMC to the board by the 
 pTLP proposal.

Benson, perhaps we need to create an FAQ around failure scenarios on your wiki 
page. Here's what I would say to address the failure scenario described by Ross.

An addition of the overseeing committee, will shield the board from
*some* of the day-to-day business of telling the pTLP that something needs to 
be fixed. So lets, break the cases down:
   1. pTLP is *really* doing fine, which means:
1.1. overseeing committee has nothing to address
1.2. board *still* has to review the reports (as it does today)
   and agrees with the overseeing committee
   END RESULT: no additional work for the board

   2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee:
2.1. board expresses its concerns *directly* to the pTLP PMC
   while CCing the committee essentially pointing out something that
   fell through the cracks when it should NOT have. NOTE: a huge
   difference here is that board does NOT expect a committee to
   fix the issue, but rather makes it aware of something that should've
   been flagged by it. Only pTLP PMC can act to remedy the issue,
   nobody else can help them (they could, of course, request help,
   but again -- it has to come from them
2.2. pTLP PMC either fixes the issue. The comittee and the board are
   happy again
2.3. pTLP PMC doesn't fix the issue == GOTO #3 (we are expecting
   the level of maturity and dedication from the committee members so
   that GOTO #2 becomes impossible since the board explicitly flagged
   this issue in 2.1)
   END RESULT: no additional work for the board

   3. pTLP is NOT doing fine and it gets flagged by the committee, which means:
3.1. since committee is treated as an extension of the board, its 
authority
and the gravity of its opinion have exactly the same consequences if
the board flagged it (we may need to come up with additional steps 
for
the board to vet the committee's opinion, though)
3.2. the committee STILL is not responsible for fixing the problem, the 
PMC is.
   END RESULT: no additional work for the board

Essentially, the overseeing committee acts as an extension of the board, but 
the ultimate responsibility lies with pTLP PMCs.
In that sense the overseeing committee inherits the good and the bad sides of 
the board. More specifically:
1. it becomes a jackhammer, not a scalpel
2. it is NOT expected to fix the problem, but rather unearth it
and delegate the solution to the PMC
3. if PMC doesn't act *really* grave consequences could follow
4. the level of maturity and the size of the committee needs to be
as close to the board's level as possible. That is the part that is
nicely addressed in Benson's wiki.

Here's an elevator pitch: when it comes to running the foundation according to 
the 'Apache Way', the committee is a vice-board.

One extra thing to note, that while we can *start* this comittee as dedicated 
to Incubating projects, it will be a very natural extension to get it involved 
in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea couldn't 
have been timelier.

Honestly, I really feel we've collectively stumbled on something really 
promising here.

 It's not necessarily a bad thing and may be acceptable to the board, 
 but I don't understand why proponents of this approach feel it is a 
 solution rather than a moving of the problem.

Benson, another useful section on the wiki could be explicit listing of the 
benefits of the proposal. Here's

Re: Incubator report sign-off

2015-01-05 Thread Alan Cabrera

This statement confuses the lack of active mentors with the sheer size of the
IPMC. The problem is not the size of the IPMC. The problem is that mentors are
not doing their jobs

Sent from my iPhone

On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980)
chris.a.mattm...@jpl.nasa.gov wrote:

Yep and let all from that 170+ person committee be tracked down for
responsibility. Talk about s fun activity it's simply not scalable

Sent from my iPhone

On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH)
ross.gard...@microsoft.com wrote:

But the board is not responsible for any actions resulting from those
reviews, the IPMC is.

Ross

-Original Message-
From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov]
Sent: Monday, January 5, 2015 9:31 AM
To: general@incubator.apache.org
Subject: Re: Incubator report sign-off

Itâ€™s not a pawning off to the board - the board is already responsible for
reviewing the IPMC report which includes *all of the same detail* that the
IPMC also .. reviews.

Cheers,
Chris

-Original Message-
From: Alan D. Cabrera l...@toolazydogs.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Monday, January 5, 2015 at 8:59 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator report sign-off

On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera
l...@toolazydogs.com
wrote:

On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:

1. get rid of IPMC altogether and move to the pTLP model

This is effectively an IPMC reboot. I donâ€™t really see anything
substantially different.

At this point, I'm convinced this is the only fruitful path forward,
the rest is a shell game with responsibility. See the other thread.

3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
deteriorate into mindless tick-offs -- but at least it does
not harm).

How is it that a mentor became an IPMC member and do such an
unethical thing such as a mindless tick-off?

We're talking about human being here. The one who never ever cut
corners in his life can cast the first stone.

I think that you misunderstood my rhetorical question. It is my
experience/understanding that if a mentor makes an effort to review
reports/releases then this mentor is actually doing a good job at it.
It is my experience/understanding that the overwhelming problem is that
mentors simply go MIA and do nothing at all.

I am in favor of #3 since it holds mentors accountable. #1 is simply a
washing of our hands and pawning the problem off on the board simple
because some of us are unwilling to do uncomfortable things.

Regards,
Alan

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

B CB
[ X ÜšX KK[XZ[
[ \ [
][ X ÜšX P[ X ]Ü‹ \X K Ü™ B ÜˆY][Û˜[ [X[ K[XZ[
[ \ [
Z[[ X ]Ü‹ \X K Ü™ B

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Ð¢ÐÐ¥FòVç7V'67–RÂRÖÖ–Ã¢vVæWÂ×Vç7V'67–T–æ7VF÷æ6†Ræ÷pÐ¤f÷FF—F–öæÂ6öÖÖæG2ÂRÖÖ–Ã¢vVæWÂÖ†VÇ–æ7VF÷æ6†Ræ÷pÐ

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread John D. Ament

Perhaps then, there's a recommendation that:

- a member can be champion to only one pTLP at a time.
- a member can be mentor to no more than two pTLP at a time.

This to me looks like a good way to make sure a mentor can always do their
job - make sure they're not overloaded.

BTW these #'s (1  2) should be subjective as I'm just making guesses for
good #'s.

John

On Mon Jan 05 2015 at 7:38:24 PM Alan Cabrera l...@toolazydogs.com wrote:

 A champion is merely a mentor who has publicly committed to being an
 active mentor, in some significant capacity, of a podling.

 The creation of such a role is symptomatic of a dysfunctional organization
 where responsibility and accountability has been diluted so much it's not
 at all clear who will actually follow through with their responsibilities.

 IMO, all that's needed is two active mentors.  To get that we need to hold
 mentors accountable.  If we do that then things become simpler and we can
 get rid of champions and shepherds; two role that were created to fill the
 gaps left by unaccountable mentors.

  On Jan 5, 2015, at 3:41 PM, Benson Margulies bimargul...@gmail.com
 wrote:
 
  Back in 2013, I suggested asking the Champion to accept a very clear
  level of reporting responsibility: to write a sentence or two _every
  month_ or find someone else to do it. That's one person whom I wanted
  to ask to sign up, for the duration of an incubation, to pay enough
  attention to be able to report a basic heartbeat.
 
  ?
 
 
  On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote:
 
 
  On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:
  On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com
 wrote:
 
 
  On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
 
  On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
  javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
  On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
  wrote:
 
  The tracking part is easy, though. What's difficult is the part
  that would require us to do something with poddlings put
  on hold. Unless we come up with clear exit criteria for
  this new state -- I don't think we're solving any real problems
  here.
 
  There’s no silver bullet here, if a podling cannot whip up a mentor
 it’s
  because:
  the podling is not popular and should probably be retired anyway,
 being
  put on hold will provide impetus for the podling to seek out a new
 venue
  there are not enough mentors
  There is no way to magically solve the latter.
 
 
  You mean popular within the pool of mentors (IPMC), the project can
 still
  be popular on several other scales.
 
  I’m not speaking of popularity of mentors; I regret that choice of
 words.
  I am stating that active and healthy podlings seem to have no trouble
  attracting active mentors.
 
  The converse seems to be true.  Unhealthy podlings seem to attract
 mentors
  who have signed up out of pity and subsequently go MIA.
  I agree with the last part, I still have to see mentors volunteer for
  small
  active and healthy projects which might not be main road. Of course it
  depends on how active and healthy is defined, but as an example my
 little
  project Corinthia barely managed to get 2 mentors, while in the same
 time
  span we got 3 committers.
 
 
  Before anyone replies, I understand this is not a hard and fast rule
 but
  an imperfect qualitative observation on my part.
 
  Anyway, active and responsible mentors will eventually get to all
 podlings.
 
  I might lack experience, but why do more active mentors guarantee
 that
  the
  podling will be a better TLP ?
 
  I’m not sure who’s making that assertion.
  Well its because I cannot see why a podling need more than 1 active
  mentor
  at all timeshaving multiple is fine, to cover each other, but it
  should
  not take more than 1 mentor to learn a podling, what it needs to
  understand. The suggestion implicit says 2 mentors is the minimum
 needed
  for at podling to become a successful TLP.
 
 
 
  We try to solve the problem of mentors not being active but adding
 more
  volume. I don't believe that is the right cure.
 
  We’re not adding volume.  The volume is already there.  We’re just
 making
  the state of affairs more explicit and transparent and adding
 culpability
  for MIA mentors.
  Do we have a rule today that a podling needs at least 2 active mentors
  (if
  we have that, then we would not have a problem with sign offs, or a lot
  of
  dead podlings), at least I have not seen itthat is what I mean by
  adding volume.
 
  If just 1 mentor is active and sign off the reports, then I do not see
  the
  problem.
 
 
 
 
  I do agree with bernard that it is the podling that should ask for
  helpbut the IPMC should solve it.,
 
  Yes, it should help solve problems but if there are no mentors
 available
  there are no mentors available.
  Then the IPMC should not have accepted the podling in the first place!
 
  It is

Re: Incubator report sign-off

2015-01-05 Thread Andrew Purtell

 An addition of the overseeing committee, will shield the board from
 
*some* of the day-to-day business of telling the pTLP that something
 
needs to be fixed.

Is this pretty close to IPMC in another name?

Who gets to be on the new overseeing committee? Not current IPMC membership
right? So is that a revocation of privilege in some respects?


On Mon, Jan 5, 2015 at 3:38 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 I am clearly hitting my rate-limit with emails to general@, still since
 Ross' reply was one of the few pieces of feedback from the board,
 I'll do this one and then wait for others to chime in (Benson?).

 On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
  This proposal is not necessarily flawed, but it is incomplete.

 Couldn't agree more. But! The whole point is to try our best
 to get this:
 https://wiki.apache.org/incubator/IncubatorV2
 to completion. Your direct feedback (as a sort of proxy for the
 board) is *very* much appreciated.

  As I've said repeatedly. This simply moves the problem it does
  not solve it. Today, a project has mentors, usually it works,
  but sometimes it doesn't. When it doesn't work someone needs
  to fix it. That is the work that is being moved from the IPMC to
  the board by the pTLP proposal.

 Benson, perhaps we need to create an FAQ around failure scenarios
 on your wiki page. Here's what I would say to address the failure
 scenario described by Ross.

 An addition of the overseeing committee, will shield the board from
 *some* of the day-to-day business of telling the pTLP that something
 needs to be fixed. So lets, break the cases down:
1. pTLP is *really* doing fine, which means:
 1.1. overseeing committee has nothing to address
 1.2. board *still* has to review the reports (as it does today)
and agrees with the overseeing committee
END RESULT: no additional work for the board

2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee:
 2.1. board expresses its concerns *directly* to the pTLP PMC
while CCing the committee essentially pointing out something
 that
fell through the cracks when it should NOT have. NOTE: a huge
difference here is that board does NOT expect a committee to
fix the issue, but rather makes it aware of something that
 should've
been flagged by it. Only pTLP PMC can act to remedy the issue,
nobody else can help them (they could, of course, request help,
but again -- it has to come from them
 2.2. pTLP PMC either fixes the issue. The comittee and the board
 are
happy again
 2.3. pTLP PMC doesn't fix the issue == GOTO #3 (we are expecting
the level of maturity and dedication from the committee members
 so
that GOTO #2 becomes impossible since the board explicitly
 flagged
this issue in 2.1)
END RESULT: no additional work for the board

3. pTLP is NOT doing fine and it gets flagged by the committee, which
 means:
 3.1. since committee is treated as an extension of the board,
 its authority
 and the gravity of its opinion have exactly the same
 consequences if
 the board flagged it (we may need to come up with
 additional steps for
 the board to vet the committee's opinion, though)
 3.2. the committee STILL is not responsible for fixing the
 problem, the PMC is.
END RESULT: no additional work for the board

 Essentially, the overseeing committee acts as an extension of
 the board, but the ultimate responsibility lies with pTLP PMCs.
 In that sense the overseeing committee inherits the good and
 the bad sides of the board. More specifically:
 1. it becomes a jackhammer, not a scalpel
 2. it is NOT expected to fix the problem, but rather unearth it
 and delegate the solution to the PMC
 3. if PMC doesn't act *really* grave consequences could follow
 4. the level of maturity and the size of the committee needs to be
 as close to the board's level as possible. That is the part that is
 nicely addressed in Benson's wiki.

 Here's an elevator pitch: when it comes to running the foundation
 according to the 'Apache Way', the committee is a vice-board.

 One extra thing to note, that while we can *start* this comittee as
 dedicated
 to Incubating projects, it will be a very natural extension to get it
 involved
 in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea
 couldn't
 have been timelier.

 Honestly, I really feel we've collectively stumbled on something really
 promising here.

  It's not necessarily a bad thing and may be acceptable to the board,
  but I don't understand why proponents of this approach feel it is a
  solution rather than a moving of the problem.

 Benson, another useful section on the wiki could be explicit listing
 of the benefits of the

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)


Makes sense :)
Hadrian

On 01/05/2015 06:41 PM, Benson Margulies wrote:

Back in 2013, I suggested asking the Champion to accept a very clear
level of reporting responsibility: to write a sentence or two _every
month_ or find someone else to do it. That's one person whom I wanted
to ask to sign up, for the duration of an incubation, to pay enough
attention to be able to report a basic heartbeat.

?


On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote:


On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:

On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:


On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:


On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:


On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org

wrote:

The tracking part is easy, though. What's difficult is the part
that would require us to do something with poddlings put
on hold. Unless we come up with clear exit criteria for
this new state -- I don't think we're solving any real problems
here.

There’s no silver bullet here, if a podling cannot whip up a mentor it’s
because:
the podling is not popular and should probably be retired anyway, being
put on hold will provide impetus for the podling to seek out a new venue
there are not enough mentors
There is no way to magically solve the latter.


You mean popular within the pool of mentors (IPMC), the project can still
be popular on several other scales.

I’m not speaking of popularity of mentors; I regret that choice of words.
I am stating that active and healthy podlings seem to have no trouble
attracting active mentors.

The converse seems to be true.  Unhealthy podlings seem to attract mentors
who have signed up out of pity and subsequently go MIA.


I agree with the last part, I still have to see mentors volunteer for
small
active and healthy projects which might not be main road. Of course it
depends on how active and healthy is defined, but as an example my little
project Corinthia barely managed to get 2 mentors, while in the same time
span we got 3 committers.


Before anyone replies, I understand this is not a hard and fast rule but
an imperfect qualitative observation on my part.

Anyway, active and responsible mentors will eventually get to all podlings.


I might lack experience, but why do more active mentors guarantee that

the

podling will be a better TLP ?

I’m not sure who’s making that assertion.


Well its because I cannot see why a podling need more than 1 active
mentor
at all timeshaving multiple is fine, to cover each other, but it
should
not take more than 1 mentor to learn a podling, what it needs to
understand. The suggestion implicit says 2 mentors is the minimum needed
for at podling to become a successful TLP.



We try to solve the problem of mentors not being active but adding more
volume. I don't believe that is the right cure.

We’re not adding volume.  The volume is already there.  We’re just making
the state of affairs more explicit and transparent and adding culpability
for MIA mentors.


Do we have a rule today that a podling needs at least 2 active mentors
(if
we have that, then we would not have a problem with sign offs, or a lot
of
dead podlings), at least I have not seen itthat is what I mean by
adding volume.

If just 1 mentor is active and sign off the reports, then I do not see
the
problem.




I do agree with bernard that it is the podling that should ask for
helpbut the IPMC should solve it.,

Yes, it should help solve problems but if there are no mentors available
there are no mentors available.


Then the IPMC should not have accepted the podling in the first place!

It is simply not fair to make the life of a podling, depending on whether
or not we have mentors available (REMARK after accepting the proposal) !
If
the podling have a healthy community and are active, we cannot and should
not close it down, just because we have a mentor problem.

To me telling a podling it cannot grow its community nor make releases,
is
the same as closing it down.

Jan,

 From an idealistic perspective, you are completely right. Apache should,
once a project has been accepted, provide the support needed.

The reality is that, given the ASF's volunteer nature, that simply won't
always work.

I'd much rather we be clear with projects right up front, saying
something like:

To join the Incubator, you need one or more mentors. To get to
graduation, you will need the support of those mentors. If mentors
become unavailable, you will need to seek replacements. Unless you have
already learned the ways of the ASF and are ready to graduate, you will
need to keep engaged with your mentors. If possible, engage in the wider
ASF, and develop connections with others who might be in a position to
assist with mentorship should one or all of your current mentors become
unable to fulfill the role. 

This is, actually, what happens, and I'd

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Dave Fisher

Hi Jan,

On Jan 5, 2015, at 12:18 PM, jan i wrote:

 On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
 On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
 
 On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
 javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s
 because:
 the podling is not popular and should probably be retired anyway, being
 put on hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 
 You mean popular within the pool of mentors (IPMC), the project can still
 be popular on several other scales.
 
 I’m not speaking of popularity of mentors; I regret that choice of words.
 I am stating that active and healthy podlings seem to have no trouble
 attracting active mentors.
 
 The converse seems to be true.  Unhealthy podlings seem to attract mentors
 who have signed up out of pity and subsequently go MIA.
 
 I agree with the last part, I still have to see mentors volunteer for small
 active and healthy projects which might not be main road. Of course it
 depends on how active and healthy is defined, but as an example my little
 project Corinthia barely managed to get 2 mentors, while in the same time
 span we got 3 committers.

Does Corinthia want another mentor?

I've already started lurking on your developer list because I am quite 
interested. I don't know if I am a committer - yet.

You can add my name as a Mentor if the PPMC wants.

 
 
 Before anyone replies, I understand this is not a hard and fast rule but
 an imperfect qualitative observation on my part.
 
 Anyway, active and responsible mentors will eventually get to all podlings.
 
 I might lack experience, but why do more active mentors guarantee that
 the
 podling will be a better TLP ?
 
 I’m not sure who’s making that assertion.
 
 Well its because I cannot see why a podling need more than 1 active mentor
 at all timeshaving multiple is fine, to cover each other, but it should
 not take more than 1 mentor to learn a podling, what it needs to
 understand. The suggestion implicit says 2 mentors is the minimum needed
 for at podling to become a successful TLP.

Here are just a few reasons a podling needs multiple Mentors:

- Mentors need vacations too.
- Mentors have day jobs, sometimes these have stretches with months of 12-16 
hour days.

 
 
 
 We try to solve the problem of mentors not being active but adding more
 volume. I don't believe that is the right cure.
 
 We’re not adding volume.  The volume is already there.  We’re just making
 the state of affairs more explicit and transparent and adding culpability
 for MIA mentors.
 
 Do we have a rule today that a podling needs at least 2 active mentors (if
 we have that, then we would not have a problem with sign offs, or a lot of
 dead podlings), at least I have not seen itthat is what I mean by
 adding volume.
 
 If just 1 mentor is active and sign off the reports, then I do not see the
 problem.
 
 
 
 
 I do agree with bernard that it is the podling that should ask for
 helpbut the IPMC should solve it.,
 
 Yes, it should help solve problems but if there are no mentors available
 there are no mentors available.
 
 Then the IPMC should not have accepted the podling in the first place!
 
 It is simply not fair to make the life of a podling, depending on whether
 or not we have mentors available (REMARK after accepting the proposal) ! If
 the podling have a healthy community and are active, we cannot and should
 not close it down, just because we have a mentor problem.
 
 To me telling a podling it cannot grow its community nor make releases, is
 the same as closing it down.

There can be lots of reasons mentors might not be engaged. Nothing may be 
happening in the podling community. I can think of an example - ODF Toolkit.

Best Regards,
Dave

 
 rgds
 jan i.
 
 
 
 
 
 
 Regards,
 Alan
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 


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

RE: Incubator report sign-off

Thanks Roman, this looks like a really good step forward.

With these modifications this proposal is very similar to my original proposal 
to have a subset of the PMC act like the board and have all the authority of 
the board when dealing with podlings/pTLP or any other incubation vehicle we 
might want to try. I think I first made it about three years ago and have 
repeated it numerous times over the years, including recently in these thread. 
The first time I proposed this it got watered down into the shepherds role 
(which certainly helped but is not complete).

I've talked to Sam about leveraging the tools we use for the board here in the 
IPMC. He says it would require a little work on both the tools and the 
processes but he is game for it. He's ready to discuss onlist if this is 
something that people want to explore, as am I.

It also occurs to me that this same committee could perform the periodic 
reviews Rich is proposing, using the same tooling.

Any other of the many proposals can also work within this construct. Nothing 
here should be seen as mutually exclusive. All I'm trying to do is ensure that 
some group of people take responsibility.

A bit of a rant follows feel free to stop reading now, I leave it for those who 
want to see into my reasoning ...

Let's think about the work a Director should do when reviewing a report. It’s 
not reading the report and then ticking a box. It's reading a report, comparing 
it to previous reports. Taking a quick look at the tone of emails on the dev 
list. Looking at commit activity. Checking the private list is not too active  
and more. We have some great tools (thanks Sam) for helping with this process, 
but it's still time consuming. We also have the concept of Shepherds. Those 
shepherds are expected to fully review a projects report and status. They will 
typically spend 10 minutes more than other directors and will be able to answer 
any questions that come up in the meeting from other directors.

To really review a project properly takes a good 10 mins for non-shepherds and 
20-30 minutes for shepherds (at least that is how long *I* spend on each 
report, I think most, if not all, directors would say the same). This is the 
case if there is no difficulties. If there are difficulties you can be talking 
about hours. 

Even with no problems this is around half a day *extra* work for each 
*volunteer* board member to review the podling/pTLP/whetever reports properly. 
I don't know about other Directors but I can't afford another half day of 
distractions from my day job - my employer is already being very generous with 
my time for the ASF.

As an example of how long it takes to decide whether or not action is taken let 
me give you two concrete examples. Last night I spent just over four hours 
reviewing the archives of a TLP to see if a potential problem was actually a 
problem. I've spent maybe another 2 hours in email threads on the topic. For 
another project a different director has spent what I would estimate to be at 
least three hours reviewing and addressing an issue while I've spent maybe an 
hour tracking those threads to see if I need to  help out. That's just in the 
last week, just the items I'm aware of and it doesn't address other things the 
directors do on a weekly basis.

If, however, we run the IPMC like the board with formal review meetings with 
identified responsible people (Bensons committee if you prefer that over my 
earlier proposals) then things start to look more manageable because the 
responsibility remains delegated across a larger team of people who are 
accountable. It gives a group of individuals the authority to act if and when 
they need to, just as the board does for TLPs. It need not be surgical (that's 
what mentors are for), but it does need to act. It also gives that group the 
recognition that they deserve do doing a job well.

This is very similar to Bensons proposal with your modifications below. It just 
removes the need for the board to take on additional responsibility which, in 
my opinion, it doesn't have the time for even if one or two directors do (those 
directors can volunteer that time to the IPMC either as part of the core 
committee, to count ticks in boxes, to properly review podling status or to 
conduct parallel pTLP experiments or whetever).


Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, January 5, 2015 3:39 PM
To: general@incubator.apache.org; Benson Margulies
Subject: Re: Incubator report sign-off

I am clearly hitting my rate-limit with emails to general@, still since Ross' 
reply was one of the few pieces of feedback from the board, I'll do this one 
and then wait for others to chime in (Benson?).

On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:
 This proposal is not necessarily

RE: Incubator report sign-off

Careful... most mentors do a great job. The problem is when all mentors fade 
away (which as volunteers they are entitled to do) and the IPMC doesn't notice.

Ross

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-Original Message-
From: Alan Cabrera [mailto:l...@toolazydogs.com] 
Sent: Monday, January 5, 2015 4:50 PM
To: general@incubator.apache.org
Subject: Re: Incubator report sign-off

This statement confuses the lack of active mentors with the sheer size of the 
IPMC.  The problem is not the size of the IPMC. The problem is that mentors are 
not doing their jobs

Sent from my iPhone

 On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 Yep and let all from that 170+ person committee be tracked down for 
 responsibility. Talk about s fun activity it's simply not scalable
 
 Sent from my iPhone
 
 On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 But the board is not responsible for any actions resulting from those 
 reviews, the IPMC is.
 
 Ross
 
 -Original Message-
 From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov]
 Sent: Monday, January 5, 2015 9:31 AM
 To: general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 Itâ€™s not a pawning off to the board - the board is already responsible for 
 reviewing the IPMC report which includes *all of the same detail* that the 
 IPMC also .. reviews.
 
 Cheers,
 Chris
 
 
 
 -Original Message-
 From: Alan D. Cabrera l...@toolazydogs.com
 Reply-To: general@incubator.apache.org 
 general@incubator.apache.org
 Date: Monday, January 5, 2015 at 8:59 AM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 
 On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera 
 l...@toolazydogs.com
 wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
 1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I donâ€™t really see anything 
 substantially different.
 
 At this point, I'm convinced this is the only fruitful path 
 forward, the rest is a shell game with responsibility. See the other 
 thread.
 
 3. patch the current process with starting to drop the mentors from
 the project who don't sign off. This will essentially serve
 as a heartbeat for mentors (now, in my opinion it'll quickly
deteriorate into mindless tick-offs -- but at least it does 
 not harm).
 
 How is it that a mentor became an IPMC member and do such an 
 unethical thing such as a mindless tick-off?
 
 We're talking about human being here. The one who never ever cut 
 corners in his life can cast the first stone.
 
 I think that you misunderstood my rhetorical question.  It is my 
 experience/understanding that if a mentor makes an effort to review 
 reports/releases then this mentor is actually doing a good job at it.
 It is my experience/understanding that the overwhelming problem is 
 that mentors simply go MIA and do nothing at all.
 
 I am in favor of #3 since it holds mentors accountable.  #1 is 
 simply a washing of our hands and pawning the problem off on the 
 board simple because some of us are unwilling to do uncomfortable things.
 
 
 Regards,
 Alan
 
 
 
 
 
 
 
 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 B 
 C
 B  [  X  ÜšX KK[XZ[  [ \ [ ][  X  ÜšX P[  X ]Ü‹ \X K Ü™ B  
 ÜˆY][Û˜[  [X[  K[XZ[  [ \ [ Z[[  X ]Ü‹ \X K Ü™ B
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 Ð¢
 ÐÐ¥Fò 
 Vç7V'67–RÂRÖÖ–Ã¢vVæWÂ×Vç7V'67–T–æ7VF÷æ6†Ræ÷pÐ¤f÷FF
 —F–öæÂ6öÖÖæG2ÂRÖÖ–Ã¢vVæWÂÖ†VÇ–æ7VF÷æ6†Ræ÷pÐ

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

RE: Binary Convenience Package Dependencies

2015-01-05 Thread Dennis E. Hamilton

Interesting.  I had not read that passage with a critical eye until just now ...

 -- replying below to --
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Monday, January 5, 2015 17:41
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies

Hi,

I would strongly recommend that you review with legal, in addition to the
incubator on this type of question.

If I look here: http://www.apache.org/legal/3party.html
MPL is listed under Category B, which has the following associated with it:

Although the source must not be included in Apache products, the NOTICE
file, which is required to be included in each ASF distribution, must point
to the source form of the included binary (more on that in the forthcoming
Receiving and Releasing Contributions document).

orcmid
   I don't see how this is going to work in the case of redistributables
   for which source is not supplied and is not open.  

   What come immediately to mind are the Microsoft Windows redistributables
   for native runtime libraries that are commonly installed with those
   convenience binaries that depend on their presence.  

   Installing a JVM or a .NET Framework for internal use by a binary
   would probably raise the same issues.

   Of course, when the ASF project doesn't actually build the redistributed
   binary artifact, it's not easy to point to *the* source either.
/orcmid

This implies to me that you must include a link in your NOTICE to the
source code.  This doesn't mean you need to distribute the source, nor add
a download option (from my perspective).

orcmid
   I think the minimum is to link to the source *of* the code.  Whether that is
   direct to the source code might not even be the best choice, depending on
   circumstances, even if possible.
/orcmid

John

On Mon Jan 05 2015 at 12:53:41 PM Alex Harui aha...@adobe.com wrote:

 Hi, anybody willing to try to answer this?

 Thanks,
 -Alex

 On 12/22/14, 8:11 AM, Alex Harui aha...@adobe.com wrote:

 Hi,

 I have some questions about Binary Convenience Packages:

 1) In [1] it says: the binary/bytecode package .. may only add
 binary/bytecode files that are the result of compiling that version of the
 source code release”.  An Apache Flex SDK source package has a build
 script that downloads jars such as Saxon and JavaCC.  Does the text I
 quoted mean that the binary package cannot bundle Saxon and JavaCC because
 we did not compile those jars from their sources?  Or does “compiling”
 really mean “running the build script on”?

 2) In [2] it says for Category B: By including only the object/binary
 form, there is less exposed surface area of the third-party work from
 which a work might be derived; this addresses the second guiding principle
 of this policy. By attaching a prominent label to the distribution and
 requiring an explicit action by the user to get the reciprocally-licensed
 source, users are less likely to be unaware of restrictions significantly
 different from those of the Apache License.”  Does “including” means
 “bundling”?  If so, the quoted text must be referencing binary packages
 and not source packages since source packages can never include
 object/binary forms.  Or does “including” also refer to build scripts that
 download an MPL jar like Saxon?

 2A) If your build script downloads an MPL jar, must it provide an option
 to download the source?

 2B) If your build script downloads an MPL jar, is any other additional
 warning or explicit action required?

 2C) If your binary package bundles an MPL jar (assuming the answer to #1
 allows it), must it provide an option to download the source?

 Thanks,
 -Alex

 [1] http://www.apache.org/dev/release.html
 [2] http://www.apache.org/legal/resolved.html

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

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

Re: Incubator report sign-off

2015-01-05 Thread Mattmann, Chris A (3980)

Yep and let all from that 170+ person committee be tracked down for 
responsibility. Talk about s fun activity it's simply not scalable 

Sent from my iPhone

 On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 But the board is not responsible for any actions resulting from those 
 reviews, the IPMC is.
 
 Ross
 
 -Original Message-
 From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] 
 Sent: Monday, January 5, 2015 9:31 AM
 To: general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 It’s not a pawning off to the board - the board is already responsible for 
 reviewing the IPMC report which includes *all of the same detail* that the 
 IPMC also .. reviews.
 
 Cheers,
 Chris
 
 
 
 -Original Message-
 From: Alan D. Cabrera l...@toolazydogs.com
 Reply-To: general@incubator.apache.org general@incubator.apache.org
 Date: Monday, January 5, 2015 at 8:59 AM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 
 On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera 
 l...@toolazydogs.com
 wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
  1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I don’t really see anything 
 substantially different.
 
 At this point, I'm convinced this is the only fruitful path forward, 
 the rest is a shell game with responsibility. See the other thread.
 
  3. patch the current process with starting to drop the mentors from
  the project who don't sign off. This will essentially serve
  as a heartbeat for mentors (now, in my opinion it'll quickly
 deteriorate into mindless tick-offs -- but at least it does 
 not harm).
 
 How is it that a mentor became an IPMC member and do such an 
 unethical thing such as a mindless tick-off?
 
 We're talking about human being here. The one who never ever cut 
 corners in his life can cast the first stone.
 
 I think that you misunderstood my rhetorical question.  It is my 
 experience/understanding that if a mentor makes an effort to review 
 reports/releases then this mentor is actually doing a good job at it.  
 It is my experience/understanding that the overwhelming problem is that 
 mentors simply go MIA and do nothing at all.
 
 I am in favor of #3 since it holds mentors accountable.  #1 is simply a 
 washing of our hands and pawning the problem off on the board simple 
 because some of us are unwilling to do uncomfortable things.
 
 
 Regards,
 Alan
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 B CB  
 [  X  ܚX KK[XZ[
  [ \ [
 ][  X  ܚX P[  X ]܋ \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
  [ \ [
 Z[[  X ]܋ \X K ܙ B
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Ted Dunning

When I sign up for helping a project, especially as champion, this is a
very reasonable request.



On Mon, Jan 5, 2015 at 3:41 PM, Benson Margulies bimargul...@gmail.com
wrote:

 Back in 2013, I suggested asking the Champion to accept a very clear
 level of reporting responsibility: to write a sentence or two _every
 month_ or find someone else to do it. That's one person whom I wanted
 to ask to sign up, for the duration of an incubation, to pay enough
 attention to be able to report a basic heartbeat.

 ?


 On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote:
 
 
  On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:
  On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com
 wrote:
 
  
   On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
  
On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
   
   
On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
 
   wrote:
   
The tracking part is easy, though. What's difficult is the part
that would require us to do something with poddlings put
on hold. Unless we come up with clear exit criteria for
this new state -- I don't think we're solving any real problems
here.
   
There’s no silver bullet here, if a podling cannot whip up a
 mentor it’s
because:
the podling is not popular and should probably be retired anyway,
 being
put on hold will provide impetus for the podling to seek out a new
 venue
there are not enough mentors
There is no way to magically solve the latter.
   
   
You mean popular within the pool of mentors (IPMC), the project can
 still
be popular on several other scales.
  
   I’m not speaking of popularity of mentors; I regret that choice of
 words.
   I am stating that active and healthy podlings seem to have no trouble
   attracting active mentors.
  
   The converse seems to be true.  Unhealthy podlings seem to attract
 mentors
   who have signed up out of pity and subsequently go MIA.
  
  I agree with the last part, I still have to see mentors volunteer for
  small
  active and healthy projects which might not be main road. Of course it
  depends on how active and healthy is defined, but as an example my
 little
  project Corinthia barely managed to get 2 mentors, while in the same
 time
  span we got 3 committers.
 
  
   Before anyone replies, I understand this is not a hard and fast rule
 but
   an imperfect qualitative observation on my part.
  
   Anyway, active and responsible mentors will eventually get to all
 podlings.
  
I might lack experience, but why do more active mentors guarantee
 that
   the
podling will be a better TLP ?
  
   I’m not sure who’s making that assertion.
  
  Well its because I cannot see why a podling need more than 1 active
  mentor
  at all timeshaving multiple is fine, to cover each other, but it
  should
  not take more than 1 mentor to learn a podling, what it needs to
  understand. The suggestion implicit says 2 mentors is the minimum needed
  for at podling to become a successful TLP.
 
 
  
We try to solve the problem of mentors not being active but adding
 more
volume. I don't believe that is the right cure.
  
   We’re not adding volume.  The volume is already there.  We’re just
 making
   the state of affairs more explicit and transparent and adding
 culpability
   for MIA mentors.
  
  Do we have a rule today that a podling needs at least 2 active mentors
  (if
  we have that, then we would not have a problem with sign offs, or a lot
  of
  dead podlings), at least I have not seen itthat is what I mean by
  adding volume.
 
  If just 1 mentor is active and sign off the reports, then I do not see
  the
  problem.
 
 
 
  
I do agree with bernard that it is the podling that should ask for
helpbut the IPMC should solve it.,
  
   Yes, it should help solve problems but if there are no mentors
 available
   there are no mentors available.
  
  Then the IPMC should not have accepted the podling in the first place!
 
  It is simply not fair to make the life of a podling, depending on
 whether
  or not we have mentors available (REMARK after accepting the proposal) !
  If
  the podling have a healthy community and are active, we cannot and
 should
  not close it down, just because we have a mentor problem.
 
  To me telling a podling it cannot grow its community nor make releases,
  is
  the same as closing it down.
 
  Jan,
 
  From an idealistic perspective, you are completely right. Apache should,
  once a project has been accepted, provide the support needed.
 
  The reality is that, given the ASF's volunteer nature, that simply won't
  always work.
 
  I'd much rather we be clear with projects right up front, saying
  something like:
 
  To join the Incubator, you need one or more mentors. To get to
  graduation, you will need the support of those mentors. If mentors
  become unavailable,

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Alan Cabrera

A champion is merely a mentor who has publicly committed to being an active 
mentor, in some significant capacity, of a podling.  

The creation of such a role is symptomatic of a dysfunctional organization 
where responsibility and accountability has been diluted so much it's not at 
all clear who will actually follow through with their responsibilities.

IMO, all that's needed is two active mentors.  To get that we need to hold 
mentors accountable.  If we do that then things become simpler and we can get 
rid of champions and shepherds; two role that were created to fill the gaps 
left by unaccountable mentors.

 On Jan 5, 2015, at 3:41 PM, Benson Margulies bimargul...@gmail.com wrote:
 
 Back in 2013, I suggested asking the Champion to accept a very clear
 level of reporting responsibility: to write a sentence or two _every
 month_ or find someone else to do it. That's one person whom I wanted
 to ask to sign up, for the duration of an incubation, to pay enough
 attention to be able to report a basic heartbeat.
 
 ?
 
 
 On Mon, Jan 5, 2015 at 3:57 PM, Upayavira u...@odoko.co.uk wrote:
 
 
 On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:
 On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
 On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
 
 On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
 javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s
 because:
 the podling is not popular and should probably be retired anyway, being
 put on hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 
 You mean popular within the pool of mentors (IPMC), the project can still
 be popular on several other scales.
 
 I’m not speaking of popularity of mentors; I regret that choice of words.
 I am stating that active and healthy podlings seem to have no trouble
 attracting active mentors.
 
 The converse seems to be true.  Unhealthy podlings seem to attract mentors
 who have signed up out of pity and subsequently go MIA.
 I agree with the last part, I still have to see mentors volunteer for
 small
 active and healthy projects which might not be main road. Of course it
 depends on how active and healthy is defined, but as an example my little
 project Corinthia barely managed to get 2 mentors, while in the same time
 span we got 3 committers.
 
 
 Before anyone replies, I understand this is not a hard and fast rule but
 an imperfect qualitative observation on my part.
 
 Anyway, active and responsible mentors will eventually get to all podlings.
 
 I might lack experience, but why do more active mentors guarantee that
 the
 podling will be a better TLP ?
 
 I’m not sure who’s making that assertion.
 Well its because I cannot see why a podling need more than 1 active
 mentor
 at all timeshaving multiple is fine, to cover each other, but it
 should
 not take more than 1 mentor to learn a podling, what it needs to
 understand. The suggestion implicit says 2 mentors is the minimum needed
 for at podling to become a successful TLP.
 
 
 
 We try to solve the problem of mentors not being active but adding more
 volume. I don't believe that is the right cure.
 
 We’re not adding volume.  The volume is already there.  We’re just making
 the state of affairs more explicit and transparent and adding culpability
 for MIA mentors.
 Do we have a rule today that a podling needs at least 2 active mentors
 (if
 we have that, then we would not have a problem with sign offs, or a lot
 of
 dead podlings), at least I have not seen itthat is what I mean by
 adding volume.
 
 If just 1 mentor is active and sign off the reports, then I do not see
 the
 problem.
 
 
 
 
 I do agree with bernard that it is the podling that should ask for
 helpbut the IPMC should solve it.,
 
 Yes, it should help solve problems but if there are no mentors available
 there are no mentors available.
 Then the IPMC should not have accepted the podling in the first place!
 
 It is simply not fair to make the life of a podling, depending on whether
 or not we have mentors available (REMARK after accepting the proposal) !
 If
 the podling have a healthy community and are active, we cannot and should
 not close it down, just because we have a mentor problem.
 
 To me telling a podling it cannot grow its community nor make releases,
 is
 the same as closing it down.
 
 Jan,
 
 From an idealistic perspective, you are completely right. Apache should,
 once a project has been accepted, provide the support needed.

Re: Incubator report sign-off

2015-01-05 Thread Alan Cabrera

Yes which is why I am proposing for less change than what others are proposing.

Sent from my iPhone

 On Jan 5, 2015, at 5:07 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 Careful... most mentors do a great job. The problem is when all mentors fade 
 away (which as volunteers they are entitled to do) and the IPMC doesn't 
 notice.
 
 Ross
 
 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation
 
 -Original Message-
 From: Alan Cabrera [mailto:l...@toolazydogs.com] 
 Sent: Monday, January 5, 2015 4:50 PM
 To: general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 This statement confuses the lack of active mentors with the sheer size of the 
 IPMC.  The problem is not the size of the IPMC. The problem is that mentors 
 are not doing their jobs
 
 Sent from my iPhone
 
 On Jan 5, 2015, at 3:41 PM, Mattmann, Chris A (3980) 
 chris.a.mattm...@jpl.nasa.gov wrote:
 
 Yep and let all from that 170+ person committee be tracked down for 
 responsibility. Talk about s fun activity it's simply not scalable
 
 Sent from my iPhone
 
 On Jan 5, 2015, at 1:08 PM, Ross Gardler (MS OPEN TECH) 
 ross.gard...@microsoft.com wrote:
 
 But the board is not responsible for any actions resulting from those 
 reviews, the IPMC is.
 
 Ross
 
 -Original Message-
 From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov]
 Sent: Monday, January 5, 2015 9:31 AM
 To: general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 ItÃ¢â‚¬â„¢s not a pawning off to the board - the board is already 
 responsible for reviewing the IPMC report which includes *all of the same 
 detail* that the IPMC also .. reviews.
 
 Cheers,
 Chris
 
 
 
 -Original Message-
 From: Alan D. Cabrera l...@toolazydogs.com
 Reply-To: general@incubator.apache.org
 general@incubator.apache.org
 Date: Monday, January 5, 2015 at 8:59 AM
 To: general@incubator.apache.org general@incubator.apache.org
 Subject: Re: Incubator report sign-off
 
 
 On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera 
 l...@toolazydogs.com
 wrote:
 
 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:
 
 1. get rid of IPMC altogether and move to the pTLP model
 
 This is effectively an IPMC reboot.  I donÃ¢â‚¬â„¢t really see anything 
 substantially different.
 
 At this point, I'm convinced this is the only fruitful path 
 forward, the rest is a shell game with responsibility. See the other 
 thread.
 
 3. patch the current process with starting to drop the mentors from
the project who don't sign off. This will essentially serve
as a heartbeat for mentors (now, in my opinion it'll quickly
   deteriorate into mindless tick-offs -- but at least it does 
 not harm).
 
 How is it that a mentor became an IPMC member and do such an 
 unethical thing such as a mindless tick-off?
 
 We're talking about human being here. The one who never ever cut 
 corners in his life can cast the first stone.
 
 I think that you misunderstood my rhetorical question.  It is my 
 experience/understanding that if a mentor makes an effort to review 
 reports/releases then this mentor is actually doing a good job at it.
 It is my experience/understanding that the overwhelming problem is 
 that mentors simply go MIA and do nothing at all.
 
 I am in favor of #3 since it holds mentors accountable.  #1 is 
 simply a washing of our hands and pawning the problem off on the 
 board simple because some of us are unwilling to do uncomfortable things.
 
 
 Regards,
 Alan
 
 
 
 
 
 
 
 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 B 
 C
 B  [  X  ÃœÅ¡X KK[XZ[  [ \ [ ][  X  ÃœÅ¡X P[  X ]Ãœâ€¹ \X K Ãœâ„¢ 
 B  
 ÃœË†Y][Ã›Ëœ[  [X[  K[XZ[  [ \ [ Z[[  X ]Ãœâ€¹ \X K Ãœâ„¢ B
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 ÃÂ¢Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’Ã’
 ÃÃÂ¥FÃ² 
 VÃ§7V'67â€“RÃ‚RÃ–Ã–â€“ÃƒÂ¢vVÃ¦WÃ‚Ã—VÃ§7V'67â€“Tâ€“Ã¦7VFÃ·Ã¦6â€
  RÃ¦Ã·pÃÂ¤fÃ·FF
 â€”Fâ€“Ã¶Ã¦Ã‚6Ã¶Ã–Ã–Ã¦G2Ã‚RÃ–Ã–â€“ÃƒÂ¢vVÃ¦WÃ‚Ã–â€ 
 VÃ‡â€“Ã¦7VFÃ·Ã¦6â€ RÃ¦Ã·pÃ
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary Convenience Package Dependencies

2015-01-05 Thread John D. Ament

On Mon Jan 05 2015 at 9:18:48 PM Dennis E. Hamilton dennis.hamil...@acm.org
wrote:

 Interesting.  I had not read that passage with a critical eye until just
 now ...

  -- replying below to --
 From: John D. Ament [mailto:johndam...@apache.org]
 Sent: Monday, January 5, 2015 17:41
 To: general@incubator.apache.org
 Subject: Re: Binary Convenience Package Dependencies

 Hi,

 I would strongly recommend that you review with legal, in addition to the
 incubator on this type of question.

 If I look here: http://www.apache.org/legal/3party.html
 MPL is listed under Category B, which has the following associated with it:

 Although the source must not be included in Apache products, the NOTICE
 file, which is required to be included in each ASF distribution, must point
 to the source form of the included binary (more on that in the forthcoming
 Receiving and Releasing Contributions document).

 orcmid
I don't see how this is going to work in the case of redistributables
for which source is not supplied and is not open.

What come immediately to mind are the Microsoft Windows redistributables
for native runtime libraries that are commonly installed with those
convenience binaries that depend on their presence.

Installing a JVM or a .NET Framework for internal use by a binary
would probably raise the same issues.

Of course, when the ASF project doesn't actually build the redistributed
binary artifact, it's not easy to point to *the* source either.
 /orcmid

 This implies to me that you must include a link in your NOTICE to the
 source code.  This doesn't mean you need to distribute the source, nor add
 a download option (from my perspective).

 orcmid
I think the minimum is to link to the source *of* the code.  Whether
 that is
direct to the source code might not even be the best choice, depending
 on
circumstances, even if possible.
 /orcmid

My interpretation of this (since I deal with this on internal stuff every 3
months or so) has always been that it's a link to the source code, not a
link to the source of the source code.

 John

 On Mon Jan 05 2015 at 12:53:41 PM Alex Harui aha...@adobe.com wrote:

  Hi, anybody willing to try to answer this?

  Thanks,
  -Alex

  On 12/22/14, 8:11 AM, Alex Harui aha...@adobe.com wrote:

  Hi,

  I have some questions about Binary Convenience Packages:

  1) In [1] it says: the binary/bytecode package .. may only add
  binary/bytecode files that are the result of compiling that version of
 the
  source code release”.  An Apache Flex SDK source package has a build
  script that downloads jars such as Saxon and JavaCC.  Does the text I
  quoted mean that the binary package cannot bundle Saxon and JavaCC
 because
  we did not compile those jars from their sources?  Or does “compiling”
  really mean “running the build script on”?

  2) In [2] it says for Category B: By including only the object/binary
  form, there is less exposed surface area of the third-party work from
  which a work might be derived; this addresses the second guiding
 principle
  of this policy. By attaching a prominent label to the distribution and
  requiring an explicit action by the user to get the
 reciprocally-licensed
  source, users are less likely to be unaware of restrictions
 significantly
  different from those of the Apache License.”  Does “including” means
  “bundling”?  If so, the quoted text must be referencing binary packages
  and not source packages since source packages can never include
  object/binary forms.  Or does “including” also refer to build scripts
 that
  download an MPL jar like Saxon?

  2A) If your build script downloads an MPL jar, must it provide an option
  to download the source?

  2B) If your build script downloads an MPL jar, is any other additional
  warning or explicit action required?

  2C) If your binary package bundles an MPL jar (assuming the answer to #1
  allows it), must it provide an option to download the source?

  Thanks,
  -Alex

  [1] http://www.apache.org/dev/release.html
  [2] http://www.apache.org/legal/resolved.html

  -
  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

Need write access to Wiki

2015-01-05 Thread Don Bosco Durai


Can someone please provide me write access to the incubator report wiki
pages?

My wiki id is ³bosco²

Thank you

Bosco

Re: Request edit karma for wiki


Thanks Marvin, all set.
Hadrian

On 01/05/2015 08:24 PM, Marvin Humphrey wrote:

On Mon, Jan 5, 2015 at 3:32 PM, Hadrian Zbarcea hzbar...@gmail.com wrote:

For some reason HadrianZbarcea can no longer edit the wiki. Could somebody
please grant me access.

That wiki ID wasn't listed in ContributorsGroup, nor in
Administrators.  I've added it to ContributorsGroup.


Please verify the @a.o address for the account.

I'm not sure how to do that.  So long as you can log in, though, I
believe adding you to ContributorsGroup suffices and no further action
is necessary.  Even logged in, you would not have been able to edit
the wiki before; you should be able to now.

Cheers,

Marvin Humphrey

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




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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator


+1.

I made some cosmetic changes to the list of committers and mentors. It 
should be clear now.


Hadrian


On 01/05/2015 02:04 PM, Hal Lockhart wrote:

I added a comma and the word and to the Mentors section. The Mentors are:

Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea

Do you see any other formatting errors?

Hal


-Original Message-
From: Roman Shaposhnik [mailto:ro...@shaposhnik.org]
Sent: Monday, January 05, 2015 1:24 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
into the Apache Incubator

Hi!

can you please fix the formatting issues? For example, I can't even
tell the exact list of mentors you're proposing.

Thanks,
Roman.

On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com
wrote:

I call a vote to accept OpenAz as a new Incubator project.

The proposal can be found here:
https://wiki.apache.org/incubator/OpenAZProposal

and is included below in this email.

Voting will remain open until at least January 20, 2015 23:00 ET.

Hal Lockhart

-

-

-

Abstract

OpenAz is a project to create tools and libraries to enable the

development of Attribute-based Access Control (ABAC) Systems in a
variety of languages. In general the work is at least consistent with
or actually conformant to the OASIS XACML Standard.

Proposal

Generally the work falls into two categories: ready to use tools

which implement standardized or well understood components of an ABAC
system and design proposals and proof of concept code relating to less
well understood or experimental aspects of the problem.

Much of the work to date has revolved around defining interfaces

enabling a PEP to request an access control decision from a PDP. The
XACML standard defines an abstract request format in xml and protocol
wire formats in xaml and json, but it does not specify programmatic
interfaces in any language. The standard says that the use of XML (or
JSON) is not required only the semantic equivalent.

The first Interface, AzAPI is modeled closely on the XACML defined

interface, expressed in Java. One of the goals was to support calls to
both a PDP local to the same process and a PDP in a remote server.
AzAPI includes the interface, reference code to handle things like the
many supported datatypes in XACML and glue code to mate it to the open
source Sun XACML implementation.

Because of the dependence on Sun XACML (which is XACML 2.0) the

interface was missing some XACML 3.0 features. More recently this was
corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
done by the JPMC team to support calling a remote PDP. WSo2 is also
pursuing this capability.

A second, higher level interface, PEPAPI was also defined. PEPAPI is

more intended for application developers with little knowledge of
XACML. It allows Java objects which contain attribute information to be
passed in. Conversion methods, called mappers extract information from
the objects and present it in the format expected by XACML. Some
implementers have chosen to implement PEPAPI directly against their
PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
which closely matches the Java one.

Examples of more speculative work include: proposals for registration

and dispatch of Obligation and Advice handlers, a scheme called AMF to
tell PIPs how to retrieve attributes and PIP code to implement it,
discussion of PoC code to demonstrate the use of XACML policies to
drive OAuth interations and a proposal to use XACML policies to express
OAuth scope.

ATT has recently contributed their extensive XACML framework to the

project.

The ATT framework represents the entire XACML 3.0 object set as a

collection of Java interfaces and standard implementations of those
interfaces. The ATT PDP engine is built on top of this framework and
represents a complete implementation of a XACML 3.0 PDP, including all
of the multi-decision profiles. In addition, the framework also
contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
functionality, allowing application developers to simply annotate a
Java class to provide attributes for a request. The annotation support
removes the need for application developers to learn much of the API.

The ATT framework also includes interfaces and implementations to

standardize development of PIP engines that are used by the ATT PDP
implementation, and can be used by other implementations built on top
of the ATT framework. The framework also includes interfaces and
implementations for a PAP distributed cloud infrastructure of PDP nodes
that includes support for policy distribution and pip configurations.
This PAP infrastructure includes a web application administrative
console that contains a XACML 3.0 policy editor, attribute dictionary
support, and management of PDP

Re: Need write access to Wiki

On Mon, Jan 5, 2015 at 7:34 PM, Don Bosco Durai bo...@apache.org wrote:

 Can someone please provide me write access to the incubator report wiki
 pages?

 My wiki id is ³bosco²

ID bosco added, happy wikifying.

Marvin Humphrey

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

Re: Binary Convenience Package Dependencies

2015-01-05 Thread sebb

On 6 January 2015 at 01:41, John D. Ament johndam...@apache.org wrote:
 Hi,

 I would strongly recommend that you review with legal, in addition to the
 incubator on this type of question.

 If I look here: http://www.apache.org/legal/3party.html

Please *don't* use that page.

It says:


This document represented a proposed ASF policy that was very helpful
in guiding the foundation for a number of years.
Please refer to the official version [1] that was derived from this
draft and associated feedback.


[1] http://www.apache.org/legal/resolved.html

 MPL is listed under Category B, which has the following associated with it:

 Although the source must not be included in Apache products, the NOTICE
 file, which is required to be included in each ASF distribution, must point
 to the source form of the included binary (more on that in the forthcoming
 Receiving and Releasing Contributions document).

 This implies to me that you must include a link in your NOTICE to the
 source code.  This doesn't mean you need to distribute the source, nor add
 a download option (from my perspective).

 John

 On Mon Jan 05 2015 at 12:53:41 PM Alex Harui aha...@adobe.com wrote:

 Hi, anybody willing to try to answer this?

 Thanks,
 -Alex

 On 12/22/14, 8:11 AM, Alex Harui aha...@adobe.com wrote:

 Hi,
 
 I have some questions about Binary Convenience Packages:
 
 1) In [1] it says: the binary/bytecode package .. may only add
 binary/bytecode files that are the result of compiling that version of the
 source code release”.  An Apache Flex SDK source package has a build
 script that downloads jars such as Saxon and JavaCC.  Does the text I
 quoted mean that the binary package cannot bundle Saxon and JavaCC because
 we did not compile those jars from their sources?  Or does “compiling”
 really mean “running the build script on”?
 
 2) In [2] it says for Category B: By including only the object/binary
 form, there is less exposed surface area of the third-party work from
 which a work might be derived; this addresses the second guiding principle
 of this policy. By attaching a prominent label to the distribution and
 requiring an explicit action by the user to get the reciprocally-licensed
 source, users are less likely to be unaware of restrictions significantly
 different from those of the Apache License.”  Does “including” means
 “bundling”?  If so, the quoted text must be referencing binary packages
 and not source packages since source packages can never include
 object/binary forms.  Or does “including” also refer to build scripts that
 download an MPL jar like Saxon?
 
 2A) If your build script downloads an MPL jar, must it provide an option
 to download the source?
 
 2B) If your build script downloads an MPL jar, is any other additional
 warning or explicit action required?
 
 2C) If your binary package bundles an MPL jar (assuming the answer to #1
 allows it), must it provide an option to download the source?
 
 Thanks,
 -Alex
 
 [1] http://www.apache.org/dev/release.html
 [2] http://www.apache.org/legal/resolved.html


 -
 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: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Ted Dunning

On Mon, Jan 5, 2015 at 4:59 PM, John D. Ament johndam...@apache.org wrote:

 This to me looks like a good way to make sure a mentor can always do their
 job - make sure they're not overloaded.

 BTW these #'s (1  2) should be subjective as I'm just making guesses for
 good #'s.


Not only are these numbers relatively random, they attempt to force fit one
number across all cases.

There are times when 1 mentorship would be too much for me.  There are
times when 10 would not be too much.

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)


On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.

There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
because:
the podling is not popular and should probably be retired anyway, being put on 
hold will provide impetus for the podling to seek out a new venue
there are not enough mentors
There is no way to magically solve the latter.


Regards,
Alan

Re: Binary Convenience Package Dependencies

2015-01-05 Thread Alex Harui

Hi, anybody willing to try to answer this?

Thanks,
-Alex

On 12/22/14, 8:11 AM, Alex Harui aha...@adobe.com wrote:

Hi,

I have some questions about Binary Convenience Packages:

1) In [1] it says: the binary/bytecode package .. may only add
binary/bytecode files that are the result of compiling that version of the
source code release”.  An Apache Flex SDK source package has a build
script that downloads jars such as Saxon and JavaCC.  Does the text I
quoted mean that the binary package cannot bundle Saxon and JavaCC because
we did not compile those jars from their sources?  Or does “compiling”
really mean “running the build script on”?

2) In [2] it says for Category B: By including only the object/binary
form, there is less exposed surface area of the third-party work from
which a work might be derived; this addresses the second guiding principle
of this policy. By attaching a prominent label to the distribution and
requiring an explicit action by the user to get the reciprocally-licensed
source, users are less likely to be unaware of restrictions significantly
different from those of the Apache License.”  Does “including” means
“bundling”?  If so, the quoted text must be referencing binary packages
and not source packages since source packages can never include
object/binary forms.  Or does “including” also refer to build scripts that
download an MPL jar like Saxon?

2A) If your build script downloads an MPL jar, must it provide an option
to download the source?

2B) If your build script downloads an MPL jar, is any other additional
warning or explicit action required?

2C) If your binary package bundles an MPL jar (assuming the answer to #1
allows it), must it provide an option to download the source?

Thanks,
-Alex

[1] http://www.apache.org/dev/release.html
[2] http://www.apache.org/legal/resolved.html


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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)


On Jan 5, 2015, at 9:14 AM, Bertrand Delacretaz bdelacre...@apache.org wrote:

 Hi,
 
 I'm resending Alan's proposal with a new subject as I think it
 deserves more attention.
 
 On Mon, Jan 5, 2015 at 1:57 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 ...Podlings would be required to have a minimum of two active mentors.  A 
 mentor is free to become inactive
 but must explicitly state this else the mentor risks being removed for not 
 performing their duties.  Podlings that
 do not have the minimum of two active mentors are put on hold until they 
 find enough mentors to fill the quota.
 Being put on hold means that no committers can be added, no PPMC members can 
 be added, and no
 releases can be performed.  It does not stop development...
 
 I like it very much...it's a small, reversible step that puts the
 burden on podlings and mentors, which are the ones who should be
 concerned about podlings going forward.
 
 It's also consistent with podlings having to find mentors to join the
 Incubator - they just have to keep on making sure their mentors are
 active, or ask for new ones when needed.
 
 As for measuring the mentors activity, I suggest simply adding a
 question to the podling reports, who are your two active mentors and
 are you happy with their activity along with requiring report
 sign-off from those two mentors.

Thanks Bertrand.  It’s a snippet of what I sent out over a year or so ago.  
I’ll resend it.


Regards,
Alan




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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Mon, Jan 5, 2015 at 6:36 PM, jan i j...@apache.org wrote:
 ...I like this idea, except putting the full responsibility of finding new
 mentors on the shoulders of the...

The Incubator PMC would help of course, but it's the podling who's in
charge of asking for mentors, in the same way as when they enter
incubation.

 ...In order to stay safe this requires at least 3 mentors at all times in
 order not to block the podling...

When we say active mentors it doesn't mean the mentor has to be here
today, replying to email within two minutes...just that they are
generally around and helping. So two active mentors is just that.

-Bertrand

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

[VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

2015-01-05 Thread Hal Lockhart

I call a vote to accept OpenAz as a new Incubator project.

The proposal can be found here: https://wiki.apache.org/incubator/OpenAZProposal

and is included below in this email.

Voting will remain open until at least January 20, 2015 23:00 ET.

Hal Lockhart

---

Abstract

OpenAz is a project to create tools and libraries to enable the development of 
Attribute-based Access Control (ABAC) Systems in a variety of languages. In 
general the work is at least consistent with or actually conformant to the 
OASIS XACML Standard.

Proposal

Generally the work falls into two categories: ready to use tools which 
implement standardized or well understood components of an ABAC system and 
design proposals and proof of concept code relating to less well understood or 
experimental aspects of the problem.

Much of the work to date has revolved around defining interfaces enabling a PEP 
to request an access control decision from a PDP. The XACML standard defines an 
abstract request format in xml and protocol wire formats in xaml and json, but 
it does not specify programmatic interfaces in any language. The standard says 
that the use of XML (or JSON) is not required only the semantic equivalent.

The first Interface, AzAPI is modeled closely on the XACML defined interface, 
expressed in Java. One of the goals was to support calls to both a PDP local to 
the same process and a PDP in a remote server. AzAPI includes the interface, 
reference code to handle things like the many supported datatypes in XACML and 
glue code to mate it to the open source Sun XACML implementation.

Because of the dependence on Sun XACML (which is XACML 2.0) the interface was 
missing some XACML 3.0 features. More recently this was corrected and WSo2 has 
mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to support 
calling a remote PDP. WSo2 is also pursuing this capability.

A second, higher level interface, PEPAPI was also defined. PEPAPI is more 
intended for application developers with little knowledge of XACML. It allows 
Java objects which contain attribute information to be passed in. Conversion 
methods, called mappers extract information from the objects and present it in 
the format expected by XACML. Some implementers have chosen to implement PEPAPI 
directly against their PDP, omitting the use of AzAPI. Naomaru Itoi defined a 
C++ interface which closely matches the Java one.

Examples of more speculative work include: proposals for registration and 
dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs 
how to retrieve attributes and PIP code to implement it, discussion of PoC code 
to demonstrate the use of XACML policies to drive OAuth interations and a 
proposal to use XACML policies to express OAuth scope.

ATT has recently contributed their extensive XACML framework to the project.

The ATT framework represents the entire XACML 3.0 object set as a collection 
of Java interfaces and standard implementations of those interfaces. The ATT 
PDP engine is built on top of this framework and represents a complete 
implementation of a XACML 3.0 PDP, including all of the multi-decision 
profiles. In addition, the framework also contains an implementation of the 
OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP API 
includes annotation functionality, allowing application developers to simply 
annotate a Java class to provide attributes for a request. The annotation 
support removes the need for application developers to learn much of the API.

The ATT framework also includes interfaces and implementations to standardize 
development of PIP engines that are used by the ATT PDP implementation, and 
can be used by other implementations built on top of the ATT framework. The 
framework also includes interfaces and implementations for a PAP distributed 
cloud infrastructure of PDP nodes that includes support for policy distribution 
and pip configurations. This PAP infrastructure includes a web application 
administrative console that contains a XACML 3.0 policy editor, attribute 
dictionary support, and management of PDP RESTful node instances. In addition, 
there are tools available for policy simulation.

Background

Access Control is in some ways the most basic IT Security service. It consists 
of making a decision about whether a particular request should be allowed and 
enforcing that decision. Aside from schemes like permission bits and Access 
Control Lists (ACLs) the most common way access control is implemented is as 
code in a server or application which typically intertwines access control 
logic with business logic, User interface and other software. This makes it 
difficult to understand, modify, analyze or even locate the security policy. 
The primary challenge of Access Control is striking the right balance between 
powerful expression and intelligibility to human

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Upayavira

An IPMC responsibility is a no responsibility.

How many people here are prepared to take on a struggling project for
the love of the Incubator, with no particular interest or investment in
the technology, or connection to the people involved?

In the end, if a project wants to join the ASF, the responsibility for
locating mentors (in the first place) and for sustaining their interest,
or locating replacements, has to rest with those who have the greatest
investment in the project. It is the only way it can work, without
giving the impression that the Incubator PMC has the ability to assign
people to a project, which is simply never going to happen.

The best we can do is provide as much guidance to projects about how to
engage their mentors, and how best to attract replacements when those
mentors go awol, or leave gracefully. That much the Incubator PMC can
do. 

Upayavira

On Mon, Jan 5, 2015, at 06:22 PM, Roman Shaposhnik wrote:
 On Mon, Jan 5, 2015 at 10:08 AM, Alan D. Cabrera l...@toolazydogs.com
 wrote:
 
  On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
  The tracking part is easy, though. What's difficult is the part
  that would require us to do something with poddlings put
  on hold. Unless we come up with clear exit criteria for
  this new state -- I don't think we're solving any real problems
  here.
 
  There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
  because:
  the podling is not popular and should probably be retired anyway, being put 
  on
  hold will provide impetus for the podling to seek out a new venue
  there are not enough mentors
  There is no way to magically solve the latter.
 
 I've always been +1 on adding a feedback question to the poddling
 reporting
 template. I'll do it shortly now that there's more consensus around the
 idea
 compared to when I first proposed it.
 
 I'm strongly -1 on adding yet another state to the Incubator state
 transition
 diagram. In my book shifting responsibility to a poddling achieves no
 useful
 purposes and is going to clutter Incubator with half-alive poddlings.
 
 The way I see this: once a poddling gets accepted it becomes an IPMC
 responsibility to make sure we empower it to be successful. It is true
 that circumstances change, but at that point it still needs to be an IPMC
 responsibility to either ponny up required mentorship resources or make
 a tough call of retirement. No need to chop the proverbial tail
 bit-by-bit.
 
 I'll rest this thread for some time now...
 
 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: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:


 On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:

  On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
  javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
  On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
 
  The tracking part is easy, though. What's difficult is the part
  that would require us to do something with poddlings put
  on hold. Unless we come up with clear exit criteria for
  this new state -- I don't think we're solving any real problems
  here.
 
  There’s no silver bullet here, if a podling cannot whip up a mentor it’s
  because:
  the podling is not popular and should probably be retired anyway, being
  put on hold will provide impetus for the podling to seek out a new venue
  there are not enough mentors
  There is no way to magically solve the latter.
 
 
  You mean popular within the pool of mentors (IPMC), the project can still
  be popular on several other scales.

 I’m not speaking of popularity of mentors; I regret that choice of words.
 I am stating that active and healthy podlings seem to have no trouble
 attracting active mentors.

 The converse seems to be true.  Unhealthy podlings seem to attract mentors
 who have signed up out of pity and subsequently go MIA.

I agree with the last part, I still have to see mentors volunteer for small
active and healthy projects which might not be main road. Of course it
depends on how active and healthy is defined, but as an example my little
project Corinthia barely managed to get 2 mentors, while in the same time
span we got 3 committers.


 Before anyone replies, I understand this is not a hard and fast rule but
 an imperfect qualitative observation on my part.

 Anyway, active and responsible mentors will eventually get to all podlings.

  I might lack experience, but why do more active mentors guarantee that
 the
  podling will be a better TLP ?

 I’m not sure who’s making that assertion.

Well its because I cannot see why a podling need more than 1 active mentor
at all timeshaving multiple is fine, to cover each other, but it should
not take more than 1 mentor to learn a podling, what it needs to
understand. The suggestion implicit says 2 mentors is the minimum needed
for at podling to become a successful TLP.



  We try to solve the problem of mentors not being active but adding more
  volume. I don't believe that is the right cure.

 We’re not adding volume.  The volume is already there.  We’re just making
 the state of affairs more explicit and transparent and adding culpability
 for MIA mentors.

Do we have a rule today that a podling needs at least 2 active mentors (if
we have that, then we would not have a problem with sign offs, or a lot of
dead podlings), at least I have not seen itthat is what I mean by
adding volume.

If just 1 mentor is active and sign off the reports, then I do not see the
problem.




  I do agree with bernard that it is the podling that should ask for
  helpbut the IPMC should solve it.,

 Yes, it should help solve problems but if there are no mentors available
 there are no mentors available.

Then the IPMC should not have accepted the podling in the first place!

It is simply not fair to make the life of a podling, depending on whether
or not we have mentors available (REMARK after accepting the proposal) ! If
the podling have a healthy community and are active, we cannot and should
not close it down, just because we have a mentor problem.

To me telling a podling it cannot grow its community nor make releases, is
the same as closing it down.

rgds
jan i.






 Regards,
 Alan


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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Mon, Jan 5, 2015 at 10:08 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.

 There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
 because:
 the podling is not popular and should probably be retired anyway, being put on
 hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.

I've always been +1 on adding a feedback question to the poddling reporting
template. I'll do it shortly now that there's more consensus around the idea
compared to when I first proposed it.

I'm strongly -1 on adding yet another state to the Incubator state transition
diagram. In my book shifting responsibility to a poddling achieves no useful
purposes and is going to clutter Incubator with half-alive poddlings.

The way I see this: once a poddling gets accepted it becomes an IPMC
responsibility to make sure we empower it to be successful. It is true
that circumstances change, but at that point it still needs to be an IPMC
responsibility to either ponny up required mentorship resources or make
a tough call of retirement. No need to chop the proverbial tail bit-by-bit.

I'll rest this thread for some time now...

Thanks,
Roman.

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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

Hi!

can you please fix the formatting issues? For example,
I can't even tell the exact list of mentors you're proposing.

Thanks,
Roman.

On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com wrote:
 I call a vote to accept OpenAz as a new Incubator project.

 The proposal can be found here: 
 https://wiki.apache.org/incubator/OpenAZProposal

 and is included below in this email.

 Voting will remain open until at least January 20, 2015 23:00 ET.

 Hal Lockhart

 ---

 Abstract

 OpenAz is a project to create tools and libraries to enable the development 
 of Attribute-based Access Control (ABAC) Systems in a variety of languages. 
 In general the work is at least consistent with or actually conformant to the 
 OASIS XACML Standard.

 Proposal

 Generally the work falls into two categories: ready to use tools which 
 implement standardized or well understood components of an ABAC system and 
 design proposals and proof of concept code relating to less well understood 
 or experimental aspects of the problem.

 Much of the work to date has revolved around defining interfaces enabling a 
 PEP to request an access control decision from a PDP. The XACML standard 
 defines an abstract request format in xml and protocol wire formats in xaml 
 and json, but it does not specify programmatic interfaces in any language. 
 The standard says that the use of XML (or JSON) is not required only the 
 semantic equivalent.

 The first Interface, AzAPI is modeled closely on the XACML defined interface, 
 expressed in Java. One of the goals was to support calls to both a PDP local 
 to the same process and a PDP in a remote server. AzAPI includes the 
 interface, reference code to handle things like the many supported datatypes 
 in XACML and glue code to mate it to the open source Sun XACML implementation.

 Because of the dependence on Sun XACML (which is XACML 2.0) the interface was 
 missing some XACML 3.0 features. More recently this was corrected and WSo2 
 has mated it to their XACML 3.0 PDP. Some work was done by the JPMC team to 
 support calling a remote PDP. WSo2 is also pursuing this capability.

 A second, higher level interface, PEPAPI was also defined. PEPAPI is more 
 intended for application developers with little knowledge of XACML. It allows 
 Java objects which contain attribute information to be passed in. Conversion 
 methods, called mappers extract information from the objects and present it 
 in the format expected by XACML. Some implementers have chosen to implement 
 PEPAPI directly against their PDP, omitting the use of AzAPI. Naomaru Itoi 
 defined a C++ interface which closely matches the Java one.

 Examples of more speculative work include: proposals for registration and 
 dispatch of Obligation and Advice handlers, a scheme called AMF to tell PIPs 
 how to retrieve attributes and PIP code to implement it, discussion of PoC 
 code to demonstrate the use of XACML policies to drive OAuth interations and 
 a proposal to use XACML policies to express OAuth scope.

 ATT has recently contributed their extensive XACML framework to the project.

 The ATT framework represents the entire XACML 3.0 object set as a collection 
 of Java interfaces and standard implementations of those interfaces. The ATT 
 PDP engine is built on top of this framework and represents a complete 
 implementation of a XACML 3.0 PDP, including all of the multi-decision 
 profiles. In addition, the framework also contains an implementation of the 
 OASIS XACML 3.0 RESTful API v1.0 and XACML JSON Profile v1.0 WD 14. The PEP 
 API includes annotation functionality, allowing application developers to 
 simply annotate a Java class to provide attributes for a request. The 
 annotation support removes the need for application developers to learn much 
 of the API.

 The ATT framework also includes interfaces and implementations to 
 standardize development of PIP engines that are used by the ATT PDP 
 implementation, and can be used by other implementations built on top of the 
 ATT framework. The framework also includes interfaces and implementations 
 for a PAP distributed cloud infrastructure of PDP nodes that includes support 
 for policy distribution and pip configurations. This PAP infrastructure 
 includes a web application administrative console that contains a XACML 3.0 
 policy editor, attribute dictionary support, and management of PDP RESTful 
 node instances. In addition, there are tools available for policy simulation.

 Background

 Access Control is in some ways the most basic IT Security service. It 
 consists of making a decision about whether a particular request should be 
 allowed and enforcing that decision. Aside from schemes like permission bits 
 and Access Control Lists (ACLs) the most common way access control is 
 implemented is as code in a server or application which typically intertwines 
 access control

Podlings should be in charge of their mentors (was: Incubator report sign-off)

On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:


 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

  The tracking part is easy, though. What's difficult is the part
  that would require us to do something with poddlings put
  on hold. Unless we come up with clear exit criteria for
  this new state -- I don't think we're solving any real problems
  here.

 There’s no silver bullet here, if a podling cannot whip up a mentor it’s
 because:
 the podling is not popular and should probably be retired anyway, being
 put on hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.


You mean popular within the pool of mentors (IPMC), the project can still
be popular on several other scales.

I might lack experience, but why do more active mentors guarantee that the
podling will be a better TLP ?

We try to solve the problem of mentors not being active but adding more
volume. I don't believe that is the right cure.

I do agree with bernard that it is the podling that should ask for
helpbut the IPMC should solve it.,


rgds
jan i



 Regards,
 Alan



-- 
Sent from My iPad, sorry for any misspellings.

Shepherd Notes without a Podling Report?

2015-01-05 Thread P. Taylor Goetz

Quick shepherding question: If a podling I’m assigned to shepherd fails to 
report, should I still add my comments to the incubator report?

-Taylor


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Shepherd Notes without a Podling Report?

On Mon, Jan 5, 2015 at 10:36 AM, P. Taylor Goetz ptgo...@gmail.com wrote:
 Quick shepherding question: If a podling I’m assigned to shepherd fails to 
 report,
 should I still add my comments to the incubator report?

If your feedback goes beyound stating the obvious lack of report ;-) Absolutely!

Thanks,
Roman.

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)


On Jan 5, 2015, at 10:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 10:08 AM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s 
 because:
 the podling is not popular and should probably be retired anyway, being put 
 on
 hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 I've always been +1 on adding a feedback question to the poddling reporting
 template. I'll do it shortly now that there's more consensus around the idea
 compared to when I first proposed it.
 
 I'm strongly -1 on adding yet another state to the Incubator state transition
 diagram. In my book shifting responsibility to a poddling achieves no useful
 purposes and is going to clutter Incubator with half-alive poddlings.

But that’s what we have today; we have virtually this state already.  All my 
proposal does is make things more explicit and adds accountability to mentors.

 The way I see this: once a poddling gets accepted it becomes an IPMC
 responsibility to make sure we empower it to be successful. It is true
 that circumstances change, but at that point it still needs to be an IPMC
 responsibility to either ponny up required mentorship resources or make
 a tough call of retirement. No need to chop the proverbial tail bit-by-bit.

This neatly sidesteps my assertion that there is no magical way to solve the 
problem of the dearth of active mentors.  pTLP does not solve it either.


Regards,
Alan


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

RE: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

2015-01-05 Thread Hal Lockhart

I added a comma and the word and to the Mentors section. The Mentors are: 

Emmanuel Lécharny, Colm O hEigeartaigh and Hadrian Zbarcea

Do you see any other formatting errors?

Hal

 -Original Message-
 From: Roman Shaposhnik [mailto:ro...@shaposhnik.org]
 Sent: Monday, January 05, 2015 1:24 PM
 To: general@incubator.apache.org
 Subject: Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools)
 into the Apache Incubator
 
 Hi!
 
 can you please fix the formatting issues? For example, I can't even
 tell the exact list of mentors you're proposing.
 
 Thanks,
 Roman.
 
 On Mon, Jan 5, 2015 at 10:15 AM, Hal Lockhart hal.lockh...@oracle.com
 wrote:
  I call a vote to accept OpenAz as a new Incubator project.
 
  The proposal can be found here:
  https://wiki.apache.org/incubator/OpenAZProposal
 
  and is included below in this email.
 
  Voting will remain open until at least January 20, 2015 23:00 ET.
 
  Hal Lockhart
 
  -
 -
  -
 
  Abstract
 
  OpenAz is a project to create tools and libraries to enable the
 development of Attribute-based Access Control (ABAC) Systems in a
 variety of languages. In general the work is at least consistent with
 or actually conformant to the OASIS XACML Standard.
 
  Proposal
 
  Generally the work falls into two categories: ready to use tools
 which implement standardized or well understood components of an ABAC
 system and design proposals and proof of concept code relating to less
 well understood or experimental aspects of the problem.
 
  Much of the work to date has revolved around defining interfaces
 enabling a PEP to request an access control decision from a PDP. The
 XACML standard defines an abstract request format in xml and protocol
 wire formats in xaml and json, but it does not specify programmatic
 interfaces in any language. The standard says that the use of XML (or
 JSON) is not required only the semantic equivalent.
 
  The first Interface, AzAPI is modeled closely on the XACML defined
 interface, expressed in Java. One of the goals was to support calls to
 both a PDP local to the same process and a PDP in a remote server.
 AzAPI includes the interface, reference code to handle things like the
 many supported datatypes in XACML and glue code to mate it to the open
 source Sun XACML implementation.
 
  Because of the dependence on Sun XACML (which is XACML 2.0) the
 interface was missing some XACML 3.0 features. More recently this was
 corrected and WSo2 has mated it to their XACML 3.0 PDP. Some work was
 done by the JPMC team to support calling a remote PDP. WSo2 is also
 pursuing this capability.
 
  A second, higher level interface, PEPAPI was also defined. PEPAPI is
 more intended for application developers with little knowledge of
 XACML. It allows Java objects which contain attribute information to be
 passed in. Conversion methods, called mappers extract information from
 the objects and present it in the format expected by XACML. Some
 implementers have chosen to implement PEPAPI directly against their
 PDP, omitting the use of AzAPI. Naomaru Itoi defined a C++ interface
 which closely matches the Java one.
 
  Examples of more speculative work include: proposals for registration
 and dispatch of Obligation and Advice handlers, a scheme called AMF to
 tell PIPs how to retrieve attributes and PIP code to implement it,
 discussion of PoC code to demonstrate the use of XACML policies to
 drive OAuth interations and a proposal to use XACML policies to express
 OAuth scope.
 
  ATT has recently contributed their extensive XACML framework to the
 project.
 
  The ATT framework represents the entire XACML 3.0 object set as a
 collection of Java interfaces and standard implementations of those
 interfaces. The ATT PDP engine is built on top of this framework and
 represents a complete implementation of a XACML 3.0 PDP, including all
 of the multi-decision profiles. In addition, the framework also
 contains an implementation of the OASIS XACML 3.0 RESTful API v1.0 and
 XACML JSON Profile v1.0 WD 14. The PEP API includes annotation
 functionality, allowing application developers to simply annotate a
 Java class to provide attributes for a request. The annotation support
 removes the need for application developers to learn much of the API.
 
  The ATT framework also includes interfaces and implementations to
 standardize development of PIP engines that are used by the ATT PDP
 implementation, and can be used by other implementations built on top
 of the ATT framework. The framework also includes interfaces and
 implementations for a PAP distributed cloud infrastructure of PDP nodes
 that includes support for policy distribution and pip configurations.
 This PAP infrastructure includes a web application administrative
 console that contains a XACML 3.0 policy editor, attribute dictionary
 support, and management of PDP RESTful node instances. In addition,
 there are

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)


On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:

 On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
 javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
 
 
 On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 
 The tracking part is easy, though. What's difficult is the part
 that would require us to do something with poddlings put
 on hold. Unless we come up with clear exit criteria for
 this new state -- I don't think we're solving any real problems
 here.
 
 There’s no silver bullet here, if a podling cannot whip up a mentor it’s
 because:
 the podling is not popular and should probably be retired anyway, being
 put on hold will provide impetus for the podling to seek out a new venue
 there are not enough mentors
 There is no way to magically solve the latter.
 
 
 You mean popular within the pool of mentors (IPMC), the project can still
 be popular on several other scales.

I’m not speaking of popularity of mentors; I regret that choice of words.  I am 
stating that active and healthy podlings seem to have no trouble attracting 
active mentors.

The converse seems to be true.  Unhealthy podlings seem to attract mentors who 
have signed up out of pity and subsequently go MIA.

Before anyone replies, I understand this is not a hard and fast rule but an 
imperfect qualitative observation on my part.

Anyway, active and responsible mentors will eventually get to all podlings.

 I might lack experience, but why do more active mentors guarantee that the
 podling will be a better TLP ?

I’m not sure who’s making that assertion.

 We try to solve the problem of mentors not being active but adding more
 volume. I don't believe that is the right cure.

We’re not adding volume.  The volume is already there.  We’re just making the 
state of affairs more explicit and transparent and adding culpability for MIA 
mentors.

 I do agree with bernard that it is the podling that should ask for
 helpbut the IPMC should solve it.,

Yes, it should help solve problems but if there are no mentors available there 
are no mentors available.


Regards,
Alan


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

Re: Shepherd Notes without a Podling Report?

2015-01-05 Thread John D. Ament

I found it useful to help determine if the podling is simply not answering
messages, vs a podling that maybe didn't get marvin's notice.

On Mon Jan 05 2015 at 1:45:00 PM Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Mon, Jan 5, 2015 at 10:36 AM, P. Taylor Goetz ptgo...@gmail.com
 wrote:
  Quick shepherding question: If a podling I’m assigned to shepherd fails
 to report,
  should I still add my comments to the incubator report?

 If your feedback goes beyound stating the obvious lack of report ;-)
 Absolutely!

 Thanks,
 Roman.

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)

2015-01-05 Thread Upayavira



On Mon, Jan 5, 2015, at 08:18 PM, jan i wrote:
 On 5 January 2015 at 20:06, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 
  On Jan 5, 2015, at 10:26 AM, jan i j...@apache.org wrote:
 
   On Monday, January 5, 2015, Alan D. Cabrera l...@toolazydogs.com
   javascript:_e(%7B%7D,'cvml','l...@toolazydogs.com'); wrote:
  
  
   On Jan 5, 2015, at 9:21 AM, Roman Shaposhnik ro...@shaposhnik.org
  wrote:
  
   The tracking part is easy, though. What's difficult is the part
   that would require us to do something with poddlings put
   on hold. Unless we come up with clear exit criteria for
   this new state -- I don't think we're solving any real problems
   here.
  
   There’s no silver bullet here, if a podling cannot whip up a mentor it’s
   because:
   the podling is not popular and should probably be retired anyway, being
   put on hold will provide impetus for the podling to seek out a new venue
   there are not enough mentors
   There is no way to magically solve the latter.
  
  
   You mean popular within the pool of mentors (IPMC), the project can still
   be popular on several other scales.
 
  I’m not speaking of popularity of mentors; I regret that choice of words.
  I am stating that active and healthy podlings seem to have no trouble
  attracting active mentors.
 
  The converse seems to be true.  Unhealthy podlings seem to attract mentors
  who have signed up out of pity and subsequently go MIA.
 
 I agree with the last part, I still have to see mentors volunteer for
 small
 active and healthy projects which might not be main road. Of course it
 depends on how active and healthy is defined, but as an example my little
 project Corinthia barely managed to get 2 mentors, while in the same time
 span we got 3 committers.
 
 
  Before anyone replies, I understand this is not a hard and fast rule but
  an imperfect qualitative observation on my part.
 
  Anyway, active and responsible mentors will eventually get to all podlings.
 
   I might lack experience, but why do more active mentors guarantee that
  the
   podling will be a better TLP ?
 
  I’m not sure who’s making that assertion.
 
 Well its because I cannot see why a podling need more than 1 active
 mentor
 at all timeshaving multiple is fine, to cover each other, but it
 should
 not take more than 1 mentor to learn a podling, what it needs to
 understand. The suggestion implicit says 2 mentors is the minimum needed
 for at podling to become a successful TLP.
 
 
 
   We try to solve the problem of mentors not being active but adding more
   volume. I don't believe that is the right cure.
 
  We’re not adding volume.  The volume is already there.  We’re just making
  the state of affairs more explicit and transparent and adding culpability
  for MIA mentors.
 
 Do we have a rule today that a podling needs at least 2 active mentors
 (if
 we have that, then we would not have a problem with sign offs, or a lot
 of
 dead podlings), at least I have not seen itthat is what I mean by
 adding volume.
 
 If just 1 mentor is active and sign off the reports, then I do not see
 the
 problem.
 
 
 
 
   I do agree with bernard that it is the podling that should ask for
   helpbut the IPMC should solve it.,
 
  Yes, it should help solve problems but if there are no mentors available
  there are no mentors available.
 
 Then the IPMC should not have accepted the podling in the first place!
 
 It is simply not fair to make the life of a podling, depending on whether
 or not we have mentors available (REMARK after accepting the proposal) !
 If
 the podling have a healthy community and are active, we cannot and should
 not close it down, just because we have a mentor problem.
 
 To me telling a podling it cannot grow its community nor make releases,
 is
 the same as closing it down.

Jan,

From an idealistic perspective, you are completely right. Apache should,
once a project has been accepted, provide the support needed. 

The reality is that, given the ASF's volunteer nature, that simply won't
always work.

I'd much rather we be clear with projects right up front, saying
something like: 

To join the Incubator, you need one or more mentors. To get to
graduation, you will need the support of those mentors. If mentors
become unavailable, you will need to seek replacements. Unless you have
already learned the ways of the ASF and are ready to graduate, you will
need to keep engaged with your mentors. If possible, engage in the wider
ASF, and develop connections with others who might be in a position to
assist with mentorship should one or all of your current mentors become
unable to fulfill the role. 

This is, actually, what happens, and I'd much rather we just said it
like that :-)

Upayavira

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

RE: Incubator report sign-off

But the board is not responsible for any actions resulting from those reviews, 
the IPMC is.

Ross

-Original Message-
From: Mattmann, Chris A (3980) [mailto:chris.a.mattm...@jpl.nasa.gov] 
Sent: Monday, January 5, 2015 9:31 AM
To: general@incubator.apache.org
Subject: Re: Incubator report sign-off

It’s not a pawning off to the board - the board is already responsible for 
reviewing the IPMC report which includes *all of the same detail* that the IPMC 
also .. reviews.

Cheers,
Chris

-Original Message-
From: Alan D. Cabrera l...@toolazydogs.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Monday, January 5, 2015 at 8:59 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: Re: Incubator report sign-off

On Jan 5, 2015, at 8:22 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Mon, Jan 5, 2015 at 5:05 AM, Alan D. Cabrera 
l...@toolazydogs.com
wrote:

 On Dec 22, 2014, at 8:42 AM, Roman Shaposhnik r...@apache.org wrote:

   1. get rid of IPMC altogether and move to the pTLP model

 This is effectively an IPMC reboot.  I don’t really see anything 
substantially different.

 At this point, I'm convinced this is the only fruitful path forward, 
 the rest is a shell game with responsibility. See the other thread.

   3. patch the current process with starting to drop the mentors from
   the project who don't sign off. This will essentially serve
   as a heartbeat for mentors (now, in my opinion it'll quickly
  deteriorate into mindless tick-offs -- but at least it does 
not harm).

 How is it that a mentor became an IPMC member and do such an 
unethical thing such as a mindless tick-off?

 We're talking about human being here. The one who never ever cut 
 corners in his life can cast the first stone.

I think that you misunderstood my rhetorical question.  It is my 
experience/understanding that if a mentor makes an effort to review 
reports/releases then this mentor is actually doing a good job at it.  
It is my experience/understanding that the overwhelming problem is that 
mentors simply go MIA and do nothing at all.

I am in favor of #3 since it holds mentors accountable.  #1 is simply a 
washing of our hands and pawning the problem off on the board simple 
because some of us are unwilling to do uncomfortable things.

Regards,
Alan

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

B CB  [  
X  ܚX KK[XZ[
  [ \ [
][  X  ܚX P[  X ]܋ \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
  [ \ [
Z[[  X ]܋ \X K ܙ B

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

Re: Podlings should be in charge of their mentors (was: Incubator report sign-off)