date:20150726

Note, there must be the binding +1 for a release. This means either three 
active mentors our some assistance from the IPMC. This is fine, some IPMC 
members are very experienced in this regard and are very helpful (as well as 
reasonable, that is understanding when something's a blocker and when it's not).

My biggest concern is not releases (which thread days are much better). My 
concern is people not being involved with a podling until an IPMC engagement is 
needed, then folks come out of the woodwork and start pushing judgments from on 
high. That's not how it works.

The IPMC needs to ensure mentors are doing their job during incubation, not 
after it.  I agree there IPMC should act more like the board in its oversight. 
That means two things:

1) get our of the way unless a problem is identified during the normal 
reporting process
2) ensure mentors are doing their job when reporting to the IPMC

In other words, hands on during reporting. Hands of at ask other times.

Sent from my Windows Phone

From: Niclas Hedhmanmailto:nic...@hedhman.org
Sent: ‎7/‎26/‎2015 8:08 AM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org wrote:

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors.

No, I don't necessarily mean that you need 3 mentors either. One active
mentor would be fine with me. Empower the podling to stand on its own feet.
The Incubation disclaimers are plenty warning, otherwise it would be full
releases.

Take a poll among podlings and ask Do you want to be more autonomous from
the IPMC? and see what they say...

Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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

2015-07-26 Thread jan i

On Sunday, July 26, 2015, Don Bosco Durai bo...@apache.org wrote:

 My only concern is now the mentor(s) need to check everything before
 approving. In my experience, during the early stages of the releases, lot
 of the license, naming, release location, etc. related issues were
 identified during the approval in the general@ list. Which were very
 helpful to us.

 I agree, but nothing prevents that the mentor ask when in doubt,
especially the
first one, we do not need to force every release to pass general@ for that
( unless
we don't trust the mentors).

rgds
jan i

 Knowing that the mentors are generally busy, it might be good to have an
 extra oversight.

 Take a poll among podlings and ask Do you want to be more autonomous
 from the IPMC? and see what they say...
 We should qualify what autonomous means here.


 Thanks

 Bosco



 On 7/26/15, 8:06 AM, Niclas Hedhman nic...@hedhman.org javascript:;
 wrote:

 On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org
 javascript:; wrote:
 
  The only downside of this proposal is that it assumes that every podling
  has at least three active (!) mentors.
 
 No, I don't necessarily mean that you need 3 mentors either. One active
 mentor would be fine with me. Empower the podling to stand on its own
 feet.
 The Incubation disclaimers are plenty warning, otherwise it would be full
 releases.
 
 Take a poll among podlings and ask Do you want to be more autonomous from
 the IPMC? and see what they say...
 
 Cheers
 --
 Niclas Hedhman, Software Developer
 http://zest.apache.org - New Energy for Java



 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Marvin Humphrey

 On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman nic...@hedhman.org wrote:

 About 40% of the last 100 threads on general@ is vote release...
 Cut that away is a good start in reforming the Incubator…

Many of those vote threads are very high quality and valuable.

Successful vote threads are short: a few +1 votes and it's over.  Frequently,
those +1 votes will be accompanied by a description what was reviewed.
Unsuccessful vote threads yield targeted action items and cogent explanations.
Since the end of 2013, when the Incubator community established an improved
consensus about release requirements, fewer RCs get rejected and rancor has
been rare.

On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej br...@apache.org wrote:

 It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...

Yes, we have for the most part solved the problem of RCs twisting in the wind.
Both proposals in this thread will bring that problem back.

Mentor attrition is a fundamental law of the Incubator: because Mentors are
not core contributors, they fall away at increased rate.  It is not possible
to change that fact, only to compensate for it.

The wider IPMC has a certain limited capacity for picking up the slack on
release votes.  Since the end of 2013, we have been using that precious
capacity wisely.

These proposals squander that capacity and put it all back on the Mentors.
Some of those Mentors will be unavailable when they are needed, compounding
the difficulties faced by smaller and more troubled podlings.

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

We routinely see problematic release candidates on general@incubator.  It
would seem that the expertise and temperament for exacting release QC is not
evenly distributed among the Mentor corps -- just like other valuable skills
and talents.

Since 2013, the wider IPMC in collaboration with Mentors has been working
well at cleaning up problematic releases in an expedited manner -- and once a
podling is producing clean releases regularly, it is probably nearing
graduation and will not be affected by the extra 3 days for long.  I don't see
any urgency to change this dynamic.

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

The outcome of the Ignite graduation discussion was never in doubt.  The wider
IPMC was never going to vote down graduation when there were multiple
attentive Ignite Mentors united in favor -- it was only a matter of time
before people came around.

I think the discussion was more voluminous than it needed to be, but I
attribute that to individual participants sending too many emails in one day.
1-2 per day on a given thread is a good rate.

In the meantime, interested podling observers got to witness a decent debate
on project independence and off-list dev discussion -- which is generally one
of the hardest aspects of Apache-style open development to master.

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

Recruiting Mentors for podlings at any stage other than entry has always been
difficult.  It would be deeply unfair to small podlings to establish a policy
which denies this reality.

Marvin Humphrey

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

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

2015-07-26 Thread Ted Dunning


I think my own experience as a mentor over recent years is useful here.  I 
thought I understood what was necessary for apache releases when, in fact, I 
understood release requirements for releases like the ones I had previously 
seen. 

The wider by shepherds and by the general votes was a pain because of the added 
delay but it substantially increased the quality of the releases and improved 
the processes the group had.  

With more perspective now, I find that individual mentors often have somewhat 
specialized expertise and my experience was absolutely not unique. 

Marvin and Ross also make good and important points orthogonal to this. 

Sent from my iPhone

On Jul 26, 2015, at 10:08, Marvin Humphrey mar...@rectangular.com wrote:

 On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman nic...@hedhman.org wrote:
 
 About 40% of the last 100 threads on general@ is vote release...
 Cut that away is a good start in reforming the Incubator…
 
 Many of those vote threads are very high quality and valuable.
 
 Successful vote threads are short: a few +1 votes and it's over.  Frequently,
 those +1 votes will be accompanied by a description what was reviewed.
 Unsuccessful vote threads yield targeted action items and cogent explanations.
 Since the end of 2013, when the Incubator community established an improved
 consensus about release requirements, fewer RCs get rejected and rancor has
 been rare.
 
 On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej br...@apache.org wrote:
 
 It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...
 
 Yes, we have for the most part solved the problem of RCs twisting in the wind.
 Both proposals in this thread will bring that problem back.
 
 Mentor attrition is a fundamental law of the Incubator: because Mentors are
 not core contributors, they fall away at increased rate.  It is not possible
 to change that fact, only to compensate for it.
 
 The wider IPMC has a certain limited capacity for picking up the slack on
 release votes.  Since the end of 2013, we have been using that precious
 capacity wisely.
 
 These proposals squander that capacity and put it all back on the Mentors.
 Some of those Mentors will be unavailable when they are needed, compounding
 the difficulties faced by smaller and more troubled podlings.
 
 Concretely: I think it's perfectly OK to review podling releases after
 the fact. The incubation disclaimer tells users clearly enough that they
 should be extra careful when using releases from incubating projects.
 
 We routinely see problematic release candidates on general@incubator.  It
 would seem that the expertise and temperament for exacting release QC is not
 evenly distributed among the Mentor corps -- just like other valuable skills
 and talents.
 
 Since 2013, the wider IPMC in collaboration with Mentors has been working
 well at cleaning up problematic releases in an expedited manner -- and once a
 podling is producing clean releases regularly, it is probably nearing
 graduation and will not be affected by the extra 3 days for long.  I don't see
 any urgency to change this dynamic.
 
 The other frustration is of course evident in the Ignite graduation
 discussion.
 
 The outcome of the Ignite graduation discussion was never in doubt.  The wider
 IPMC was never going to vote down graduation when there were multiple
 attentive Ignite Mentors united in favor -- it was only a matter of time
 before people came around.
 
 I think the discussion was more voluminous than it needed to be, but I
 attribute that to individual participants sending too many emails in one day.
 1-2 per day on a given thread is a good rate.
 
 In the meantime, interested podling observers got to witness a decent debate
 on project independence and off-list dev discussion -- which is generally one
 of the hardest aspects of Apache-style open development to master.
 
 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors. That doesn't always happen; and
 currently we expect the podling to chase down inactive mentors or find
 new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
 active role in finding mentors for podlings.
 
 Recruiting Mentors for podlings at any stage other than entry has always been
 difficult.  It would be deeply unfair to small podlings to establish a policy
 which denies this reality.
 
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Don Bosco Durai

My only concern is now the mentor(s) need to check everything before
approving. In my experience, during the early stages of the releases, lot
of the license, naming, release location, etc. related issues were
identified during the approval in the general@ list. Which were very
helpful to us.

Knowing that the mentors are generally busy, it might be good to have an
extra oversight.

Take a poll among podlings and ask Do you want to be more autonomous
from the IPMC? and see what they say...
We should qualify what autonomous means here.


Thanks

Bosco



On 7/26/15, 8:06 AM, Niclas Hedhman nic...@hedhman.org wrote:

On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org wrote:

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors.

No, I don't necessarily mean that you need 3 mentors either. One active
mentor would be fine with me. Empower the podling to stand on its own
feet.
The Incubation disclaimers are plenty warning, otherwise it would be full
releases.

Take a poll among podlings and ask Do you want to be more autonomous from
the IPMC? and see what they say...

Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java



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

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

2015-07-26 Thread toki



On 07/26/2015 04:35 PM, jan i wrote:

 unless we don't trust the mentors

It isn't a case of not trusting the mentors, but rather, the ease with
which something can be accidentally overlooked.

Rephrased. The mentor is too close to the project, to see all of the
errors in the project.

jonathon



signature.asc
Description: OpenPGP digital signature

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator


Apologies in advance for slightly crossing threads here.

Even though I have already sent quite a lot of emails on this subject 
(12 over the past week!), I feel I must reply to some of the concerns 
and opinions expressed in the last few emails. I do not like it when 
concerns are answered with the notion that it is perhaps caused by the 
concerned party being uneducated, as I believe there are deeper issues 
at play here. Nor do I agree with any notion that the IPMC should be a 
rubber stamp.


But let's get some facts straight first:
- The champion of the project created a DISCUSS thread prior to a 
potential vote. Not a VOTE thread, but a DISCUSS thread. This implies 
that a subject is to be reviewed and discussed.
- During this discussion thread, concerns were raised by people outside 
of the IPMC.
- Members of the IPMC looked into the concerns, as any governing body 
should, and while doing so, discovered other issues that were brought to 
the attention of the podling. These issues ranged from bad wording, 
which were unfortunately favorable to a specific company, to more 
procedural issues in maintaining transparency in development.
- Some of these issues were fixed, some were debated/refuted, and some 
are 'pending' later review (chiefly cultural and procedural issues raised)


The fact that the IPMC members found other issues while investigating 
concerns does not, in my view, equal 'micro management'. I think it 
shows that having people outside the specific podling look into it can 
shed some light on matters that were perhaps overlooked by mentors, and 
that is a good thing. Very specific issues were highlighted because they 
showed exactly where the supposed disconnect in procedure was. I believe 
having specific data points to present helps a great deal in fixing 
procedures.


We can debate whether the IPMC should have found these issues earlier, 
as Ross rightfully suggests, but nonetheless, the following is (I hope) 
true:


The IPMC, just like the board of directors, trust the mentors - just 
like the board trusts the PMCs - to do their best in reporting the true 
status of a podling/project. The IPMC, just like the board, does not 
rubber-stamp blindly. If concerns are raised, the IPMC, just like the 
board, will look into issues, and if that search yields anything worth 
asking about (even if that turns out to be some other issue found during 
the investigation), then the IPMC, just like the board, will ask the 
podling/project whether this is true and whether they are currently 
working on fixing it or will fix it.


I fail to see the disconnect, nor do I see it as 'punishment from up 
high' as was suggested. There were a few emails where the tone should 
have been more polite or diplomatic (FOSSers can get quite grumpy, we 
should try our best not to), but on the whole, this discussion has been 
one of facts (specifically an inquiry into why the findings of some 
people are inconsistent with the findings of others) and policy.


We all have day jobs, we have hobbies, we have family, we have beds we 
sleep in for quite a lot of hours every day. That coupled with our other 
commitments to ASF projects makes it nigh impossible to stay up to date 
with what's going on in every single podling, which in turn means that 
when we finally do, every single thing, that should have been mentioned 
perhaps months ago, suddenly rains down on the podling within a matter 
of days. This is indeed unfortunate and not always very fair to the 
podling, but it is a result of how the incubator works and how people work.


This thread has been long, and I'm not interested in having it go on 
forever. The IPMC has given feedback to the podling, the podling has 
either complied or promised to comply with this. Given enough time for 
procedural changes to become visible and consistent, I think the mentors 
should then start a vote on graduation.


With regards,
Daniel.


On 2015-07-25 22:27, Roman Shaposhnik wrote:

On Sat, Jul 25, 2015 at 2:10 AM, Branko Čibej br...@apache.org wrote:

On 24.07.2015 21:00, Konstantin Boudnik wrote:

An an active mentor of the podling I do support the graduation. The last, to
my knowledge, concern expressed was about insufficient open discussions of the
new features on the dev@ and that has been addressed by [1]

WRT your observation: I do think the diversity part in the graduation
requirement is moot and, as this discussion shows, quite counter-productive. I
will start a separate [DISCUSS] about reconsidering its presence in the
guidelines.

[1] http://s.apache.org/vYK

Seconded.

Makes three of us. As a mentor, I fully support graduation of this podling.

Thanks,
Roman.

P.S. Also, after going through the thread, I still maintain that I have nothing
to add to what I've already said wrt. perception on what diversity requirement
really means. As somebody who's been with the IPMC for almost 5 years now
I would like to make an observation: we seem to get confused from time to

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

Wait. I think this is overstating the displeasure.

I don't see anyone saying the feedback is not valuable. I see mentors being 
asked to clearly state their recommendation with reference to the feedback. The 
thread was too long and argumentative to draw any conclusions.

I also see concerns that these issues are raised at the point of discussing 
graduation. That is too late.

This separate thread goes in a significantly different direction and should jot 
be linked to any specific discuss thread.

Sent from my Windows Phone

From: David Nalleymailto:da...@gnsa.us
Sent: ‎7/‎26/‎2015 12:36 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)


 Empower the Mentors to run the podlings, teach the newcomers and bring it
 to TLP.


As a mentor of podlings, I dislike the above idea.

Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.

Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.

Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.

--David

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

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




On 2015-07-26 10:56, jan i wrote:

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

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

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

rgds
jan i.
This is somewhat similar to the 2013 alternate release policy we have, 
whereby the first release has to do the initial IPMC clearance vote, but 
subsequent releases only need the mentors' approval. I believe our 
current policy is sound and has proven itself effective, as you can see 
by the many times a new podling's release has been caught by the policy 
watch dogs we have in the IPMC that specialize in reviewing material 
that is to be released.


Optionally, if we aim to 'save space in our inboxes', we could generate 
a new group of people on a specific ML designed for initial release 
verification, and all _first releases_ would go through that list and 
have things checked, while only sending a NOTICE to the general 
incubator list on successfully released software.


I do not, however, think we should just scrap the current rule of having 
the outside judge the initial release, as it has been shown, time after 
time, that it really does help to have this external review.


With regards,
Daniel.

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

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




On 2015-07-27 01:20, Roman Shaposhnik wrote:


I'd like to raise a somewhat orthogonal point. Mainly the fact that our
obsession with doing good work with podlings could, very well, be
obscuring a much more important issues. And given how limited
our resources of eyeballs looking at releases are -- we need to
be practical.

Now, while I couldn't agree more that IP hygiene of releases is one of
the corner  stones of what makes ASF what it is, I have to be realistic in
accepting the fact that once podling is out of the incubation and becomes a TLP
the level of external scrutiny drops by 90% and all bets are off. Some TLPs
do great releases. Some do really poor ones. Sometimes ppl notify the board.

Once again, I can't be happier that there are folks like Justin who spend
an enormous amount of their personal time helping to vet releases of
podlings. I only ask: should his (and guys like him) time be better applied
to helping foundation make sure that our TLPs are doing what they are
supposed to do as well?

I too am very delighted that we have volunteers who are both willing and 
able to help us through these somewhat dry and dusty areas of releasing 
software. I believe our time is better spent if we educate new podlings 
on proper release and IP procedures, so as to prevent these things from 
happening later on when they are released into the apache wilds with the 
273 other projects, and as such, I think it's better to have these 
checks (and the people doing the checks) in the incubator. Having said 
that, I do realize this puts a lot of pressure on very few people, and 
the asynchronicity of going back and forth between podling and incubator 
is not the optimal way. But I believe this is something the incubator 
needs to teach podlings.


What if, for example, we were to come up with a more automated and 
educational system for this, so as to get it faster through the human 
control? We already have Rat that does most of this, so couldn't we make 
a super rat that does a bit more, specifically designed to educate the 
incubating podlings, maybe a web interface where you just throw a 
tarball at it and it'll tell you what needs to be improved.


Sure, it would have a significant cost in people hours at first, but if 
the Incubator is going to be around for another decade or more, it would 
definitely pay off in the end and make initial releases faster.


I'd be happy to collaborate with others on this, if there is an interest 
in giving it a go.


With regards,
Daniel.

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

Re: [VOTE] Graduate Lens from the Incubator

2015-07-26 Thread Sreekanth Ramakrishnan

+1

Thanks
Sreekanth


 On Jul 24, 2015, at 6:19 PM, Jakob Homan jgho...@gmail.com wrote:

 Following two positive discussions[1][2] about its curent status, the
 Lens community has voted[3] to graduate from the Incubator.  The vote
 passed with 22 +1s:

 Binding +1 x 14: {Jakob, Jean-Baptiste, Yash, Amareshwari, Sharad,
 Raghavendra, Raju, Jaideep, Suma, Himanshu, Rajat, Srikanth, Chris,
 Arshad}

 Non-binding +1 x 8: {Jothi, Kartheek, Tushar, Nitin, Pranav, Deepak,
 Ajay, Naresh}

 The Lens community has:
 * completed all required paperwork:
 https://incubator.apache.org/projects/lens.html
 * completed multiple releases (2.0.1-beta, 2.1.-beta, 2.2.0-beta)
 * completed the name check procedure:
 https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-63
 * opened nearly 700 JIRAs:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20LENS
 * voted in multiple new committers/PPMC members.
 * been recommended as ready to graduate by the Incubator's shepards:
 https://wiki.apache.org/incubator/July2015

 Therefore, I'm calling a VOTE to graduate Lens with the following
 Board resolution.  The VOTE will run 96 hours (an extra day since
 we're starting on a Friday), ending Tuesday July 28 4 PM PST.

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

 Here's my binding vote: +1.
 -Jakob

 [1] http://s.apache.org/LensGradDiscuss1
 [2] http://s.apache.org/LensGradDiscuss2
 [3] http://s.apache.org/LensGradVotePPMC

  Apache Lens graduation resolution draft
 WHEREAS, the Board of Directors deems it to be in the best interests of
 the Foundation and consistent with the Foundation's purpose to establish
 a Project Management Committee charged with the creation and maintenance
 of open-source software, for distribution at no charge to the public,
 related to unified analytics across multiple tiered data stores.

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

 RESOLVED, that the Apache Lens Project be and hereby is responsible
 for the creation and maintenance of software related to unified analytics
 across multiple tiered data stores; and be it further

 RESOLVED, that the office of Vice President, Apache Lens be and hereby
 is created, the person holding such office to serve at the direction of
 the Board of Directors as the chair of the Apache Lens Project, and to
 have primary responsibility for management of the projects within the
 scope of responsibility of the Apache Lens Project; and be it further

 RESOLVED, that the persons listed immediately below be and hereby are
 appointed to serve as the initial members of the Apache Lens Project:

 * Amareshwari Sriramadasu amareshwari at apache dot org
 * Arshad Matin arshadmatin at apache dot org
 * Gunther Hagleitner gunther at apache dot org
 * Himanshu Gahlaut himanshugahlaut at apache dot org
 * Jaideep Dhok jdhok at apache dot org
 * Jean Baptiste Onofre jbonofre at apache dot org
 * Raghavendra Singh raghavsingh at apache dot org
 * Rajat Khandelwal prongs at apache dot org
 * Raju Bairishetti raju at apache dot org
 * Sharad Agarwal sharad at apache dot org
 * Sreekanth Ramakrishnan sreekanth at apache dot org
 * Srikanth Sundarrajan sriksun at apache dot org
 * Suma Shivaprasad sumasai at apache dot org
 * Vikram Dixit vikram at apache dot org
 * Vinod Kumar Vavilapalli vinodkv at apache dot org
 * Yash Sharma yash at apache dot org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Amareshwari Sriramadasu
 be appointed to the office of Vice President, Apache Lens, to serve in
 accordance with and subject to the direction of the Board of Directors
 and the Bylaws of the Foundation until death, resignation, retirement,
 removal or disqualification, or until a successor is appointed; and be
 it further

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

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

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


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

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

David, I think we've been there before a few month ago.
In my view, you're articulating collective (IPMC) vs.
personal (mentors) responsibility.

IIRC, we came to be on different sides of that divide.

I'll repeat again what I said in that discussion: I like
the mentor responsibility model a LOT for the same
reasons I like PMCs responsibility model. We don't
expect all of the ASF membership to constantly
attend to running every project -- we expect PMC to do
that. We expect the board to be effective at striking
the balance of not micromanaging while at the same
time coming down as a ton of bricks when they do
identify an issue worth reacting to. The model works.
I don't see why it can't work for podlings.

I'll specifically abstain from commenting on the Ignite
graduation (few last paragraphs) since I'd like this
thread to be 100% separate from that discussion.

Thanks,
Roman.

On Sun, Jul 26, 2015 at 12:35 PM, David Nalley da...@gnsa.us wrote:

 Empower the Mentors to run the podlings, teach the newcomers and bring it
 to TLP.


 As a mentor of podlings, I dislike the above idea.

 Mentors get busy, they miss things, sometimes big things. Sometimes
 things that are obvious to an outsider are missed by mentors who don't
 catch it. I've certainly been guilty of missing things, and having an
 'outside IPMC member' call attention to that has caused me to go find
 not just that problem, but other problems with a podling.

 Even on smaller issues, Justin and Sebb run circles around me in
 validating that releases comply with policy. I've voted affirmatively
 on releases that Justin or Sebb has found issues; occasionally glaring
 issues. I do not think that just because I am a mentor on $project and
 they aren't invalidates concerns they may raise. I may have additional
 insight, and be able to explain things.

 Similarly, a vote was brought to the IPMC as to whether or not to
 recommend graduation. We asked people to inspect the podling and vote,
 and for some reason seem displeased when everyone doesn't unanimously
 agree with the mentors. I am not sure whether to interpret that as
 'non-mentor IPMC votes are discouraged', or whether 'dissenting
 opinions are discouraged'. But telling the body responsible (the IPMC)
 to leave podlings in its charge alone, particularly when prompted by a
 vote called by the podling itself hardly seems appropriate.

 --David

 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Konstantin Boudnik

On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote:
 On 26.07.2015 10:56, jan i wrote:
  On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:
 
  Hi,
 
  About 40% of the last 100 threads on general@ is vote release... Cut
  that
  away is a good start in reforming the Incubator…
  IMO Which provides a valuable service in showing poddlings on how to make
  good releases. Do we want to get rid of that?
 
  No that is an important service, on the other hand I also agree that the
  mentors should be guiding/running the podlings not general@
 
  Maybe we can find some middle ground.
  - Mentors run the podlings, can accept releases etc.
  - Mentors decide when a podlng can graduate (maybe with some form of, needs
  to accepted by all mentors of the project)
  - Any release must be announced (not voted) on general@, so that people
  like you have a chance of controlling it just like today.
 
  I think this would make incubator a lot more efficient, reduce our inboxes,
  and give us spare time to concentrate on other things.
 
 I like this proposal very much. One of the constant frustrations in the
 podlings I'd mentored was the delay between release bits being ready and
 the IPMC getting around to vote. It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...
 
 Concretely: I think it's perfectly OK to review podling releases after
 the fact. The incubation disclaimer tells users clearly enough that they
 should be extra careful when using releases from incubating projects.
 
 The other frustration is of course evident in the Ignite graduation
 discussion.
 
 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors. That doesn't always happen; and
 currently we expect the podling to chase down inactive mentors or find
 new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
 active role in finding mentors for podlings.
 
 Other than that, big +1.

I like the idea of the post factum release reviews. It doesn't mean that IPMC
at large aren't welcome to jump in and help with the podling release voting.
Perhaps a sane and courteous thing would be to Cc: general@ on the podling
[VOTE] thread? But +1 even as it stands right now.


One of the moot points that has came up a few times recently about the
diversity clause in the graduation guidelines. Namely:

A major criterion for graduation is to have developed an open and diverse
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

The semantic of diverse isn't clear and is being interpreted in different
ways. I'd like to propose to change the above paragraph to

A major criterion for graduation is to have developed an open and
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

to avoid possible confusing interpretations in the future.

Regards,
  Cos


signature.asc
Description: Digital signature

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator


I'll keep it short :)

I fully agree that many of these issues should have been addressed much 
earlier, it would have been better that way.
I don't think our current incubation process in tandem with this being a 
volunteer process is doing the right thing at all times, and I am more 
than willing to help look into what we can do to better this. I think 
the IPMC did the right thing by saying whoah, we need to address these 
issues first, but yes, it should have happened sooner.


We need to look into how we can, with the resources we have, assure that 
when it comes to a vote, the right procedures are in place and we know 
what to answer people who raise concerns. In this case, we were (as is 
apparent) surprised by what we discovered, and it all came at once like 
a snowball rolling down a hill. In part because we are economically 
minded people - we don't focus on an issue unless it is an issue, or 
we'd have to spend hours every day looking after 40+ podlings, in part 
because we have a system in place that is prone to cause this.


The system needs to get better so we don't end up with one huge fight at 
the end, but I think the concerns were/are genuinely valid, albeit in 
the wrong place of the process.


With regards,
Daniel.

On 2015-07-27 00:00, Ross Gardler wrote:

Daniel, I agree with almost all your points about process (I do not have an 
opinion on Ignite, the mentors have expressed their opinion based in feedback 
in this thread, the IPMC will ultimately decide on whether graduation is 
appropriate).

My complaint about process is that these things should be uncovered and discussed during 
incubation not at some gate controlled by the IPMC but triggered by mentors 
sending a Discuss thread.

The IPMC absolutely should not rubber stamp things. So why is it that the 
report process hasn't highlighted these concerns during incubation? (a genuine 
question with no accusation intended)

Sent from my Windows Phone

From: Daniel Grunomailto:humbed...@apache.org
Sent: ‎7/‎26/‎2015 1:55 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

Apologies in advance for slightly crossing threads here.

Even though I have already sent quite a lot of emails on this subject
(12 over the past week!), I feel I must reply to some of the concerns
and opinions expressed in the last few emails. I do not like it when
concerns are answered with the notion that it is perhaps caused by the
concerned party being uneducated, as I believe there are deeper issues
at play here. Nor do I agree with any notion that the IPMC should be a
rubber stamp.

But let's get some facts straight first:
- The champion of the project created a DISCUSS thread prior to a
potential vote. Not a VOTE thread, but a DISCUSS thread. This implies
that a subject is to be reviewed and discussed.
- During this discussion thread, concerns were raised by people outside
of the IPMC.
- Members of the IPMC looked into the concerns, as any governing body
should, and while doing so, discovered other issues that were brought to
the attention of the podling. These issues ranged from bad wording,
which were unfortunately favorable to a specific company, to more
procedural issues in maintaining transparency in development.
- Some of these issues were fixed, some were debated/refuted, and some
are 'pending' later review (chiefly cultural and procedural issues raised)

The fact that the IPMC members found other issues while investigating
concerns does not, in my view, equal 'micro management'. I think it
shows that having people outside the specific podling look into it can
shed some light on matters that were perhaps overlooked by mentors, and
that is a good thing. Very specific issues were highlighted because they
showed exactly where the supposed disconnect in procedure was. I believe
having specific data points to present helps a great deal in fixing
procedures.

We can debate whether the IPMC should have found these issues earlier,
as Ross rightfully suggests, but nonetheless, the following is (I hope)
true:

The IPMC, just like the board of directors, trust the mentors - just
like the board trusts the PMCs - to do their best in reporting the true
status of a podling/project. The IPMC, just like the board, does not
rubber-stamp blindly. If concerns are raised, the IPMC, just like the
board, will look into issues, and if that search yields anything worth
asking about (even if that turns out to be some other issue found during
the investigation), then the IPMC, just like the board, will ask the
podling/project whether this is true and whether they are currently
working on fixing it or will fix it.

I fail to see the disconnect, nor do I see it as 'punishment from up
high' as was suggested. There were a few emails where the tone should
have been more polite or diplomatic (FOSSers can get quite grumpy, we
should try our best not to), but on the

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

Since I am relatively new to the Incubator (given that it turns 13 in 
just 2½ month), I will ask a question that may have been answered in the 
earlier years:


Have we given any thought to some sort of mentor rotation policy?

One could argue that what we especially lack right now is the 'outsider' 
view on podlings before it is 'too late', so perhaps changing (or at 
least adding some new) mentors along the way, not just by choice, but by 
design/policy, we could perhaps, just perhaps, catch some potential 
cases of myopia or in the loop issues that seems to, arguably, be the 
cause of some of the concerns raised lately.


I realize that this, with the ASF being an all volunteer org, is not 
something you simply implement in a fortnight, but I think it's worth 
discussing.


With regards,
Daniel.

On 2015-07-26 22:33, Ted Dunning wrote:

I think my own experience as a mentor over recent years is useful here.  I 
thought I understood what was necessary for apache releases when, in fact, I 
understood release requirements for releases like the ones I had previously 
seen.

The wider by shepherds and by the general votes was a pain because of the added 
delay but it substantially increased the quality of the releases and improved 
the processes the group had.

With more perspective now, I find that individual mentors often have somewhat 
specialized expertise and my experience was absolutely not unique.

Marvin and Ross also make good and important points orthogonal to this.





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

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

On Sun, Jul 26, 2015 at 1:56 AM, jan i j...@apache.org wrote:
 No that is an important service, on the other hand I also agree that the
 mentors should be guiding/running the podlings not general@

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

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

I really like this idea. Huge +1. How can we, please, make it a reality?
Do we need to draft a new set of by laws/policies for the IPMC or is
there a more gradual approach to putting this into practice?

Thanks,
Roman.

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

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

On Sun, Jul 26, 2015 at 9:50 AM, toki toki.kant...@gmail.com wrote:


 On 07/26/2015 04:35 PM, jan i wrote:

 unless we don't trust the mentors

 It isn't a case of not trusting the mentors, but rather, the ease with
 which something can be accidentally overlooked.

 Rephrased. The mentor is too close to the project, to see all of the
 errors in the project.

An how is this different from TLP's PMC?

Thanks,
Roman.

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

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

Hi Daniel

On Sun, Jul 26, 2015 at 1:55 PM, Daniel Gruno humbed...@apache.org wrote:
 Apologies in advance for slightly crossing threads here.

I'll try to keep you straight in replying to the parts that belong to
this thread ;-)

 But let's get some facts straight first:
 - The champion of the project created a DISCUSS thread prior to a potential
 vote. Not a VOTE thread, but a DISCUSS thread. This implies that a subject
 is to be reviewed and discussed.
 - During this discussion thread, concerns were raised by people outside of
 the IPMC.

So far so good.

 - Members of the IPMC looked into the concerns, as any governing body
 should, and while doing so, discovered other issues that were brought to the
 attention of the podling. These issues ranged from bad wording, which were
 unfortunately favorable to a specific company, to more procedural issues in
 maintaining transparency in development.

 - Some of these issues were fixed, some were debated/refuted, and some are
 'pending' later review (chiefly cultural and procedural issues raised)

And here's where things get interesting. First of all, let me say that I'm
extremely grateful for *actionable* concerns that were expressed on
this thread. Things like sill cut-n-paste errors. I really do appreciate IPMC's
time spent of reviewing the proposed board resolution.

Then, there were concerns that are non-actionable (or at least poorly
specified) and then there were concerns that had nothing to do with
whether the podling is ready to be an *average* TLP.

Because you see, the proposed resolution that started this thread is NOT
about whether we all believe Ignite is going to be a poster child and a
role model for all the TLPs in the foundation, but rather whether we believe
it can self govern according to the broad principles of the Apache Way.

IOW, in my view (a view of somebody who spent quite a few months
directly with this and other podlings) some of the concerns are OK to
address after the project becomes a TLP. There's always something
to be improved. IPMC voting on a podling becoming a TLP doesn't
somehow invalidate what you and other have uncovered it just believes
that the podling is mature enough to address feedback as a TLP. That's
what the vote is really all about.

So, long story short:
   1. I believe all actionable concerns were take care of. Please correct
me if I am wrong here (by listing the actionable concerns that were NOT
taken care of).

2. Since I still don't seem to have anybody reply to my direct question:
http://s.apache.org/twy
I need to repeat this request here again: if anybody still has *actionable*
concerns on whether this podling can function as an *average* TLP please
reply with succinct bullet items.

I'm sorry but the rest of the replies belong to that other separate thread.

Thanks,
Roman.

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

RE: [DISCUSSION] Graduate Ignite from the Apache Incubator

Daniel, I agree with almost all your points about process (I do not have an 
opinion on Ignite, the mentors have expressed their opinion based in feedback 
in this thread, the IPMC will ultimately decide on whether graduation is 
appropriate).

My complaint about process is that these things should be uncovered and 
discussed during incubation not at some gate controlled by the IPMC but 
triggered by mentors sending a Discuss thread.

The IPMC absolutely should not rubber stamp things. So why is it that the 
report process hasn't highlighted these concerns during incubation? (a genuine 
question with no accusation intended)

Sent from my Windows Phone

From: Daniel Grunomailto:humbed...@apache.org
Sent: ‎7/‎26/‎2015 1:55 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

Apologies in advance for slightly crossing threads here.

Even though I have already sent quite a lot of emails on this subject
(12 over the past week!), I feel I must reply to some of the concerns
and opinions expressed in the last few emails. I do not like it when
concerns are answered with the notion that it is perhaps caused by the
concerned party being uneducated, as I believe there are deeper issues
at play here. Nor do I agree with any notion that the IPMC should be a
rubber stamp.

But let's get some facts straight first:
- The champion of the project created a DISCUSS thread prior to a
potential vote. Not a VOTE thread, but a DISCUSS thread. This implies
that a subject is to be reviewed and discussed.
- During this discussion thread, concerns were raised by people outside
of the IPMC.
- Members of the IPMC looked into the concerns, as any governing body
should, and while doing so, discovered other issues that were brought to
the attention of the podling. These issues ranged from bad wording,
which were unfortunately favorable to a specific company, to more
procedural issues in maintaining transparency in development.
- Some of these issues were fixed, some were debated/refuted, and some
are 'pending' later review (chiefly cultural and procedural issues raised)

The fact that the IPMC members found other issues while investigating
concerns does not, in my view, equal 'micro management'. I think it
shows that having people outside the specific podling look into it can
shed some light on matters that were perhaps overlooked by mentors, and
that is a good thing. Very specific issues were highlighted because they
showed exactly where the supposed disconnect in procedure was. I believe
having specific data points to present helps a great deal in fixing
procedures.

We can debate whether the IPMC should have found these issues earlier,
as Ross rightfully suggests, but nonetheless, the following is (I hope)
true:

The IPMC, just like the board of directors, trust the mentors - just
like the board trusts the PMCs - to do their best in reporting the true
status of a podling/project. The IPMC, just like the board, does not
rubber-stamp blindly. If concerns are raised, the IPMC, just like the
board, will look into issues, and if that search yields anything worth
asking about (even if that turns out to be some other issue found during
the investigation), then the IPMC, just like the board, will ask the
podling/project whether this is true and whether they are currently
working on fixing it or will fix it.

I fail to see the disconnect, nor do I see it as 'punishment from up
high' as was suggested. There were a few emails where the tone should
have been more polite or diplomatic (FOSSers can get quite grumpy, we
should try our best not to), but on the whole, this discussion has been
one of facts (specifically an inquiry into why the findings of some
people are inconsistent with the findings of others) and policy.

We all have day jobs, we have hobbies, we have family, we have beds we
sleep in for quite a lot of hours every day. That coupled with our other
commitments to ASF projects makes it nigh impossible to stay up to date
with what's going on in every single podling, which in turn means that
when we finally do, every single thing, that should have been mentioned
perhaps months ago, suddenly rains down on the podling within a matter
of days. This is indeed unfortunate and not always very fair to the
podling, but it is a result of how the incubator works and how people work.

This thread has been long, and I'm not interested in having it go on
forever. The IPMC has given feedback to the podling, the podling has
either complied or promised to comply with this. Given enough time for
procedural changes to become visible and consistent, I think the mentors
should then start a vote on graduation.

With regards,
Daniel.


On 2015-07-25 22:27, Roman Shaposhnik wrote:
 On Sat, Jul 25, 2015 at 2:10 AM, Branko Čibej br...@apache.org wrote:
 On 24.07.2015 21:00, Konstantin Boudnik wrote:
 An an active mentor of the podling I do

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

On Sun, Jul 26, 2015 at 3:57 PM, Daniel Gruno humbed...@apache.org wrote:


 On 2015-07-26 10:56, jan i wrote:

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

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

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

 rgds
 jan i.

 This is somewhat similar to the 2013 alternate release policy we have,
 whereby the first release has to do the initial IPMC clearance vote, but
 subsequent releases only need the mentors' approval. I believe our current
 policy is sound and has proven itself effective, as you can see by the many
 times a new podling's release has been caught by the policy watch dogs we
 have in the IPMC that specialize in reviewing material that is to be
 released.

 Optionally, if we aim to 'save space in our inboxes', we could generate a
 new group of people on a specific ML designed for initial release
 verification, and all _first releases_ would go through that list and have
 things checked, while only sending a NOTICE to the general incubator list on
 successfully released software.

 I do not, however, think we should just scrap the current rule of having the
 outside judge the initial release, as it has been shown, time after time,
 that it really does help to have this external review.

I'd like to raise a somewhat orthogonal point. Mainly the fact that our
obsession with doing good work with podlings could, very well, be
obscuring a much more important issues. And given how limited
our resources of eyeballs looking at releases are -- we need to
be practical.

Now, while I couldn't agree more that IP hygiene of releases is one of
the corner  stones of what makes ASF what it is, I have to be realistic in
accepting the fact that once podling is out of the incubation and becomes a TLP
the level of external scrutiny drops by 90% and all bets are off. Some TLPs
do great releases. Some do really poor ones. Sometimes ppl notify the board.

Once again, I can't be happier that there are folks like Justin who spend
an enormous amount of their personal time helping to vet releases of
podlings. I only ask: should his (and guys like him) time be better applied
to helping foundation make sure that our TLPs are doing what they are
supposed to do as well?

Thanks,
Roman.

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

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

2015-07-26 Thread David Nalley

On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler
ross.gard...@microsoft.com wrote:
The proposed need to announce release votes on the IPMC list is how things
were when the incubator was created. The need for IPMC to control the process
is another case of the IPMC over-reaching itself and in so doing causing
problems by creating a bottleneck in the process.

It used to be that it was only required to *notify* the IPMC of a release
vote underway. Thereby giving interested IPMC members the opportunity to
review artifacts and processes during the normal release cycle. IPMC members
were expected to cast their votes on the PPMC list where such things belong.

I'd love to see links to that - my digging didn't find it. (see below)

I'm not sure where this idea that the vote actually occurs on the IPMC list
came from but it's flat wrong in my opinion (someone may dig through the
archives and find a good reason it was changed, but my feeling is that it
changed gradually through edits-on-edits-on-edits of the incubation policy).

The fact is that the PPMC (with IPMC representation from the mentors) should
be in charge of their releases, and pretty much everything else. The IPMC
role is one of teaching the PPMC how manage itself. Mentors should do this
through mentoring and the IPMC should ensure it is done through an
appropriate level of oversight (not an inappropriate amount of control).

Consider this... The board does not bring TLP release votes to board@, why on
earth must the IPMC do so?

I've half a mind to got back the wayback machine and pull the original
incubator polices and propose them as the new policies (yes, some changes
have been good, but it seems to me that many have not)

So I couldn't find anything in 2003, but 2004 has this page[1] which
included the text:

Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC. Such approval
SHALL be given only after the Incubator PMC has followed the process
detailed in (Reference to Charter), and SHALL NOT occur until all
source has been legally transferred to the ASF.

and

Therefore, should a Podling decide it wishes to perform a release,
the Podling SHALL formally request the Incubator PMC approve such a
release. The request SHALL have the endorsement of the Mentor.

So it seems that this has been with us for a long while.

[1]
https://web.archive.org/web/20041010183702/http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A

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

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




On 2015-07-27 00:04, Ross Gardler wrote:

Wait. I think this is overstating the displeasure.

I don't see anyone saying the feedback is not valuable. I see mentors being 
asked to clearly state their recommendation with reference to the feedback. The 
thread was too long and argumentative to draw any conclusions.

I also see concerns that these issues are raised at the point of discussing 
graduation. That is too late.
At risk of nitpicking on semantics; Discussing graduation should be 
about whether or not a project is ready to graduate, should it not? 
There should not be a moment in a podling's life, past a completed 
graduation vote, where it is too late to voice your concern, 
otherwise, what's the point of having a discussion if it's expected that 
everyone agrees?


As stated elsewhere, unfortunately we have situations where a lot of 
topics that should have been covered at an earlier stage suddenly comes 
up during a graduation discussion, or in the horrible cases, during a 
graduation vote. We should strive to have as few of these moments as 
possible - possibly by redesigning the incubator process a bit to 
address this - , but I don't think we neither should nor can 'outlaw' 
this. This is the 'point of no return' so to speak, and while I would 
really love for this to be a walk in the park every single time (because 
we did our homework in time), there will be cases where both mentors and 
IPMC members have missed things (for various reasons), and until we 
actually come up with a good replacement for please take a good look at 
our podling that actually works and engages people besides the mentors, 
this will remain the point in time where podlings are under the most 
scrutiny.


To sum up: I think the attitude is a bit skewed here. We should not be 
negative about a final big push, we should be glad that it exists - as 
it shows people _can_ take the time to look into what's going on in 
podlings - and look into why this manages to garner extra effort from 
our volunteers and how we can encourage and incentivize them to do this 
at an earlier stage.


Maybe we need a 'half way' discussion/review, maybe we need something 
else. What we have right now does not seem to give the desired result.


I'll get some sleep, have some FOSS dreams (or the usual surreal ones 
with a hedgehog chasing a lion) and see if I can't come up with a more 
specific proposal for tomorrow :)


With regards,
Daniel.



This separate thread goes in a significantly different direction and should jot 
be linked to any specific discuss thread.

Sent from my Windows Phone

From: David Nalleymailto:da...@gnsa.us
Sent: ‎7/‎26/‎2015 12:36 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)


Empower the Mentors to run the podlings, teach the newcomers and bring it
to TLP.


As a mentor of podlings, I dislike the above idea.

Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.

Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.

Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.

--David

-
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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

The proposed need to announce release votes on the IPMC list is how things were 
when the incubator was created. The need for IPMC to control the process is 
another case of the IPMC over-reaching itself and in so doing causing problems 
by creating a bottleneck in the process. 

It used to be that it was only required to *notify* the IPMC of a release vote 
underway. Thereby giving interested IPMC members the opportunity to review 
artifacts and processes during the normal release cycle. IPMC members were 
expected to cast their votes on the PPMC list where such things belong. 

I'm not sure where this idea that the vote actually occurs on the IPMC list 
came from but it's flat wrong in my opinion (someone may dig through the 
archives and find a good reason it was changed, but my feeling is that it 
changed gradually through edits-on-edits-on-edits of the incubation policy). 

The fact is that the PPMC (with IPMC representation from the mentors) should be 
in charge of their releases, and pretty much everything else. The IPMC role is 
one of teaching the PPMC how manage itself. Mentors should do this through 
mentoring and the IPMC should ensure it is done through an appropriate level of 
oversight (not an inappropriate amount of control).

Consider this... The board does not bring TLP release votes to board@, why on 
earth must the IPMC do so?

I've half a mind to got back the wayback machine and pull the original 
incubator polices and propose them as the new policies (yes, some changes 
have been good, but it seems to me that many have not)

Ross

-Original Message-
From: Konstantin Boudnik [mailto:c...@apache.org] 
Sent: Sunday, July 26, 2015 5:15 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote:
 On 26.07.2015 10:56, jan i wrote:
  On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:
 
  Hi,
 
  About 40% of the last 100 threads on general@ is vote release... 
  Cut
  that
  away is a good start in reforming the Incubator…
  IMO Which provides a valuable service in showing poddlings on how 
  to make good releases. Do we want to get rid of that?
 
  No that is an important service, on the other hand I also agree that 
  the mentors should be guiding/running the podlings not general@
 
  Maybe we can find some middle ground.
  - Mentors run the podlings, can accept releases etc.
  - Mentors decide when a podlng can graduate (maybe with some form 
  of, needs to accepted by all mentors of the project)
  - Any release must be announced (not voted) on general@, so that 
  people like you have a chance of controlling it just like today.
 
  I think this would make incubator a lot more efficient, reduce our 
  inboxes, and give us spare time to concentrate on other things.
 
 I like this proposal very much. One of the constant frustrations in 
 the podlings I'd mentored was the delay between release bits being 
 ready and the IPMC getting around to vote. It's now a lot better than 
 it was a couple years ago, when in some instances it took a month or more ...
 
 Concretely: I think it's perfectly OK to review podling releases after 
 the fact. The incubation disclaimer tells users clearly enough that 
 they should be extra careful when using releases from incubating projects.
 
 The other frustration is of course evident in the Ignite graduation 
 discussion.
 
 The only downside of this proposal is that it assumes that every 
 podling has at least three active (!) mentors. That doesn't always 
 happen; and currently we expect the podling to chase down inactive 
 mentors or find new ones. If we adopt Jan's proposal, I'd expect the 
 IPMC to take a more active role in finding mentors for podlings.
 
 Other than that, big +1.

I like the idea of the post factum release reviews. It doesn't mean that IPMC 
at large aren't welcome to jump in and help with the podling release voting.
Perhaps a sane and courteous thing would be to Cc: general@ on the podling 
[VOTE] thread? But +1 even as it stands right now.


One of the moot points that has came up a few times recently about the 
diversity clause in the graduation guidelines. Namely:

A major criterion for graduation is to have developed an open and diverse
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

The semantic of diverse isn't clear and is being interpreted in different 
ways. I'd like to propose to change the above paragraph to

A major criterion for graduation is to have developed an open and
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

to avoid possible confusing interpretations in the future.

Regards,
  Cos

-
To unsubscribe,

Re: Last chance to tell your story at ApacheCON EU 2015

Hi Richard!

sorry for the belated reply (OSCON is to blame ;-))
I see that you've successfully updated the wiki. This
is great. I'm planning to do one last round of planning
within that Speed Dating/Shark Tank slot with everybody
who volunteered. Expect an email from me soon.

Thanks,
Roman.

On Wed, Jul 22, 2015 at 1:53 AM, Richard Downer rich...@apache.org wrote:
 Hi Jan,

 On Wed, 22 Jul 2015 at 09:32 jan i j...@apache.org wrote:

  Sorry I'm a bit late! I've modified the wiki page to add Brooklyn to the
  list of full talks, and volunteer myself for a shark tank talk.
 
 ??? Confused, the schedule is fixed and talks have been grouped, changes in
 the wiki page made now is
 only for historic reasons and will in no way be moved to the schedule.


 Brooklyn is on the conference schedule, we have 3 (!) talks in ApacheCon
 Core [1][2][3]. But the wiki page section Podlings with regular talks
 currently submitted didn't show Brooklyn as having a regular talk so I
 updated it. If I've misinterpreted the meaning of this section then I (or
 anyone) can revert it.

 The shark tank is different.


 Yes, I assumed that the shark tank schedule is more flexible, but I do know
 that I am late, and I may have missed my chance here.

 Cheers
 Richard

 [1]http://sched.co/3x1G
 [2]http://sched.co/3x2p
 [3]http://sched.co/3x5L

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

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