You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/07/26 10:20:19 UTC
Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
On Sun, Jul 26, 2015 at 4:27 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> #2 The #1 goal is achieved via mentorship. In fact mentorship is
> not even required
> as the case of Zest (and hopeful Yetus soon) demonstrated.
> #3 When mentorship is required IPMC entrusts the mentors to guide
> the project to graduation. It should let them do that.
> In short, I'd like to see IPMC behave more like the ASF board, and
> provide an effective
> oversight over the mentors not micro management. This is a tough
> balance, I know.
I also have this view point, sort of. I think the Incubator is "too heavy"
and currently not at all modeled after the Board (compare 9 directors with
100s of IPMC members). We don't bring Apache Hadoop Release Vetting and
Vote to the Board, it should be with the Mentors and podling community, and
after a release has been made, a line item shows up in the next report.
Empower the Mentors to run the podlings, teach the newcomers and bring it
to TLP.
This list would become a "go to"-list, for inspiration, exchange and
coordination, similar to the ComDev list or the internal Member's list.
About 40% of the last 100 threads on general@ is "vote release"... Cut that
away is a good start in reforming the Incubator...
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)
Posted by Daniel Gruno <hu...@apache.org>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Ted Dunning <te...@gmail.com>.
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 <ma...@rectangular.com> wrote:
>> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman <ni...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Marvin Humphrey <ma...@rectangular.com>.
> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman <ni...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
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 Hedhman<ma...@hedhman.org>
Sent: 7/26/2015 8:08 AM
To: general@incubator.apache.org<ma...@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)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Jul 26, 2015 at 9:50 AM, toki <to...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by toki <to...@gmail.com>.
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
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by jan i <ja...@apache.org>.
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" <niclas@hedhman.org <javascript:;>>
> wrote:
>
> >On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej <brane@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-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Don Bosco Durai <bo...@apache.org>.
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" <ni...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Niclas Hedhman <ni...@hedhman.org>.
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)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Sorry, my comment was too brief.
I understand the maturity model to be something to aspire to and that Apache Projects will always be working toward it. I mean TLPs, not podlings, although podlings should be aware of it and also aspire to it.
I was commending the structure and clarity of the maturity model as a basis, not about it being somehow held to podlings as a graduation yardstick or anything else.
I was responding in the context of Bertrand's comment,
Creating a release checklist in a structured text format
sounds like a good start anyway, so we can start with that
... .
that used the maturity model format as a suggested form.
- D
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Tuesday, August 4, 2015 10:37
To: general@incubator.apache.org; orcmid@apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 4 August 2015 at 18:46, Dennis E. Hamilton <or...@apache.org> wrote:
> +1 on how to start, with the maturity model as exemplar, is an outstanding
> idea. Thanks.
>
> (I even have a poddling in mind for stress-testing it.)
>
It is clear to me, that incubator offer many advantages...but our current
overweight to control everything is seen (and are) a negative effect,
anything
that can reduce that is good.
I think the maturity model is good, but to used with care. If I think of
the same podling as Dennis, that would clearly be a test done too early.
rgds
jan i.
>
> - Dennis
>
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: Tuesday, August 4, 2015 05:57
> To: Incubator General <ge...@incubator.apache.org>
> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
> the Apache Incubator)
>
> Hi Daniel,
>
> On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno <hu...@apache.org> wrote:
> > On 2015-08-04 13:01, Bertrand Delacretaz wrote:
> >>... IMO the Incubator PMC can very much own this checklist, and I
> >> volunteer to contribute to creating it...
>
> > If interested, I would very much like to work with you on perhaps turning
> > this into a sort of 'online compliance check' where podlings could
> upload a
> > tarball or some such, and the service would scan it for compliance, go
> > through the checklist, and report back which elements are compliant and
> > which are not...
>
> Wow, that's more ambitious than what I envisioned but I know your are
> able to do that ;-)
>
> Creating a release checklist in a structured text format sounds like a
> good start anyway, so we can start with that and if you and others
> want to turn it into an online analysis service that would be
> fantastic.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by jan i <ja...@apache.org>.
On 4 August 2015 at 18:46, Dennis E. Hamilton <or...@apache.org> wrote:
> +1 on how to start, with the maturity model as exemplar, is an outstanding
> idea. Thanks.
>
> (I even have a poddling in mind for stress-testing it.)
>
It is clear to me, that incubator offer many advantages...but our current
overweight to control everything is seen (and are) a negative effect,
anything
that can reduce that is good.
I think the maturity model is good, but to used with care. If I think of
the same podling as Dennis, that would clearly be a test done too early.
rgds
jan i.
>
> - Dennis
>
> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: Tuesday, August 4, 2015 05:57
> To: Incubator General <ge...@incubator.apache.org>
> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
> the Apache Incubator)
>
> Hi Daniel,
>
> On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno <hu...@apache.org> wrote:
> > On 2015-08-04 13:01, Bertrand Delacretaz wrote:
> >>... IMO the Incubator PMC can very much own this checklist, and I
> >> volunteer to contribute to creating it...
>
> > If interested, I would very much like to work with you on perhaps turning
> > this into a sort of 'online compliance check' where podlings could
> upload a
> > tarball or some such, and the service would scan it for compliance, go
> > through the checklist, and report back which elements are compliant and
> > which are not...
>
> Wow, that's more ambitious than what I envisioned but I know your are
> able to do that ;-)
>
> Creating a release checklist in a structured text format sounds like a
> good start anyway, so we can start with that and if you and others
> want to turn it into an online analysis service that would be
> fantastic.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by "Dennis E. Hamilton" <or...@apache.org>.
+1 on how to start, with the maturity model as exemplar, is an outstanding idea. Thanks.
(I even have a poddling in mind for stress-testing it.)
- Dennis
-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
Sent: Tuesday, August 4, 2015 05:57
To: Incubator General <ge...@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Hi Daniel,
On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno <hu...@apache.org> wrote:
> On 2015-08-04 13:01, Bertrand Delacretaz wrote:
>>... IMO the Incubator PMC can very much own this checklist, and I
>> volunteer to contribute to creating it...
> If interested, I would very much like to work with you on perhaps turning
> this into a sort of 'online compliance check' where podlings could upload a
> tarball or some such, and the service would scan it for compliance, go
> through the checklist, and report back which elements are compliant and
> which are not...
Wow, that's more ambitious than what I envisioned but I know your are
able to do that ;-)
Creating a release checklist in a structured text format sounds like a
good start anyway, so we can start with that and if you and others
want to turn it into an online analysis service that would be
fantastic.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Daniel,
On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno <hu...@apache.org> wrote:
> On 2015-08-04 13:01, Bertrand Delacretaz wrote:
>>... IMO the Incubator PMC can very much own this checklist, and I
>> volunteer to contribute to creating it...
> If interested, I would very much like to work with you on perhaps turning
> this into a sort of 'online compliance check' where podlings could upload a
> tarball or some such, and the service would scan it for compliance, go
> through the checklist, and report back which elements are compliant and
> which are not...
Wow, that's more ambitious than what I envisioned but I know your are
able to do that ;-)
Creating a release checklist in a structured text format sounds like a
good start anyway, so we can start with that and if you and others
want to turn it into an online analysis service that would be
fantastic.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Along these lines, also consider using DRAT:
http://github.com/chrismattmann/drat/
Think of it as RAT at scale with progress logs, Tika-based MIME
file identification. Presentations, videos, and docs are on the
page.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Ross Gardler <Ro...@microsoft.com>
Reply-To: "general@incubator.apache.org" <ge...@incubator.apache.org>
Date: Tuesday, August 4, 2015 at 9:12 AM
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
Subject: RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
the Apache Incubator)
>As an immediate start to having a tool to support mentors and TLPs you
>might want to consider providing a Rat service. Rat is already very
>useful.
>
>Sent from my Windows Phone
>________________________________
>From: Daniel Gruno<ma...@apache.org>
>Sent: 8/4/2015 4:15 AM
>To: general@incubator.apache.org<ma...@incubator.apache.org>
>Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
>the Apache Incubator)
>
>
>
>On 2015-08-04 13:01, Bertrand Delacretaz wrote:
>> On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik <ro...@shaposhnik.org>
>>wrote:
>>> ...Which would be totally fine and gets us back to the point Daniel
>>>and I were
>>> discussing: a release compliance team (horrible name, I know) as part
>>>of ASF....
>> IMO it's not a team that's needed, just a clear and "modular" release
>>checklist.
>>
>> By modular I mean something like our maturity model [1] where each
>> item is atomic and numbered so one could say "this release doesn't
>> comply with RM-42" and everybody knows what it's about.
>>
>> And there's no inventing new checklist items unless they are approved
>> by the PMC who owns the checklist.
>>
>> IMO the Incubator PMC can very much own this checklist, and I
>> volunteer to contribute to creating it.
>>
>> We do have a starting point at
>> http://incubator.apache.org/guides/release.html but the release
>> checklist might need more explanations, as footnotes, and its own page
>> to keep the noise low.
>>
>Hi Bertrand,
>If interested, I would very much like to work with you on perhaps
>turning this into a sort of 'online compliance check' where podlings
>could upload a tarball or some such, and the service would scan it for
>compliance, go through the checklist, and report back which elements are
>compliant and which are not. I think that this, while not being 100%
>accurate, would save a lot of time and aggravation when dealing with the
>initial release candidates, and save us a lot of time by automating what
>we tend to spend quite a lot of time doing manually.
>
>This won't solve everything, but it would really cut down on the time
>that is, in my opinion, wasted on getting a release through the IPMC,
>while still retaining the policies and rules we need in order to comply
>with our legal requirements.
>
>With regards,
>Daniel.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
As an immediate start to having a tool to support mentors and TLPs you might want to consider providing a Rat service. Rat is already very useful.
Sent from my Windows Phone
________________________________
From: Daniel Gruno<ma...@apache.org>
Sent: 8/4/2015 4:15 AM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 2015-08-04 13:01, Bertrand Delacretaz wrote:
> On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> ...Which would be totally fine and gets us back to the point Daniel and I were
>> discussing: a release compliance team (horrible name, I know) as part of ASF....
> IMO it's not a team that's needed, just a clear and "modular" release checklist.
>
> By modular I mean something like our maturity model [1] where each
> item is atomic and numbered so one could say "this release doesn't
> comply with RM-42" and everybody knows what it's about.
>
> And there's no inventing new checklist items unless they are approved
> by the PMC who owns the checklist.
>
> IMO the Incubator PMC can very much own this checklist, and I
> volunteer to contribute to creating it.
>
> We do have a starting point at
> http://incubator.apache.org/guides/release.html but the release
> checklist might need more explanations, as footnotes, and its own page
> to keep the noise low.
>
Hi Bertrand,
If interested, I would very much like to work with you on perhaps
turning this into a sort of 'online compliance check' where podlings
could upload a tarball or some such, and the service would scan it for
compliance, go through the checklist, and report back which elements are
compliant and which are not. I think that this, while not being 100%
accurate, would save a lot of time and aggravation when dealing with the
initial release candidates, and save us a lot of time by automating what
we tend to spend quite a lot of time doing manually.
This won't solve everything, but it would really cut down on the time
that is, in my opinion, wasted on getting a release through the IPMC,
while still retaining the policies and rules we need in order to comply
with our legal requirements.
With regards,
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-08-04 13:01, Bertrand Delacretaz wrote:
> On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> ...Which would be totally fine and gets us back to the point Daniel and I were
>> discussing: a release compliance team (horrible name, I know) as part of ASF....
> IMO it's not a team that's needed, just a clear and "modular" release checklist.
>
> By modular I mean something like our maturity model [1] where each
> item is atomic and numbered so one could say "this release doesn't
> comply with RM-42" and everybody knows what it's about.
>
> And there's no inventing new checklist items unless they are approved
> by the PMC who owns the checklist.
>
> IMO the Incubator PMC can very much own this checklist, and I
> volunteer to contribute to creating it.
>
> We do have a starting point at
> http://incubator.apache.org/guides/release.html but the release
> checklist might need more explanations, as footnotes, and its own page
> to keep the noise low.
>
Hi Bertrand,
If interested, I would very much like to work with you on perhaps
turning this into a sort of 'online compliance check' where podlings
could upload a tarball or some such, and the service would scan it for
compliance, go through the checklist, and report back which elements are
compliant and which are not. I think that this, while not being 100%
accurate, would save a lot of time and aggravation when dealing with the
initial release candidates, and save us a lot of time by automating what
we tend to spend quite a lot of time doing manually.
This won't solve everything, but it would really cut down on the time
that is, in my opinion, wasted on getting a release through the IPMC,
while still retaining the policies and rules we need in order to comply
with our legal requirements.
With regards,
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> ...Which would be totally fine and gets us back to the point Daniel and I were
> discussing: a release compliance team (horrible name, I know) as part of ASF....
IMO it's not a team that's needed, just a clear and "modular" release checklist.
By modular I mean something like our maturity model [1] where each
item is atomic and numbered so one could say "this release doesn't
comply with RM-42" and everybody knows what it's about.
And there's no inventing new checklist items unless they are approved
by the PMC who owns the checklist.
IMO the Incubator PMC can very much own this checklist, and I
volunteer to contribute to creating it.
We do have a starting point at
http://incubator.apache.org/guides/release.html but the release
checklist might need more explanations, as footnotes, and its own page
to keep the noise low.
-Bertrand
[1] https://community.apache.org/apache-way/apache-project-maturity-model.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Andrew Purtell <ap...@apache.org>.
Can you provide a pointer to a specific example of what you mean?
On Mon, Aug 3, 2015 at 4:06 PM, Arvind Prabhakar <ar...@apache.org> wrote:
> On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > >
> >
> > In fact, in my opinion it leads to the very unfortunate side effect of
> IPMC
> > >
> > feeling in need to justify why it exists by micromanaging podlings.
> >
> > I've been through incubation as a mentor on Phoenix, Nifi, and now
> getting
> > up to speed on Trafodion, I have not seen micromanagement of podlings.
> > Could you point out an example? Curious what you mean.
> >
>
> It is worth noting that none of the IPMC members micromanage on purpose, or
> are even aware that their actions are being interpreted as acts of
> micromanagement. From their perspective, it is their responsibility to
> guide the podling, and that is what they are trying to do. It will unfair
> to bring those out as examples of micromanagement.
>
> That said, I have personally been in positions where I have seen IPMC
> members ask - and even demand things at times - that I feel are
> unreasonable requests for the podling. The reason I do not challenge those
> is because I feel that their asks are rooted in good intentions, and that
> the IPMC in its current form encourages such involvement and authority. At
> the same time I also worry about the state of the podling and what this
> does to their way of thinking about Apache and the Incubator.
>
> Regards,
> Arvind Prabhakar
>
>
> >
> >
> > On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> > > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament <jo...@apache.org>
> > > wrote:
> > > > I wonder how much of the silence is a notion of "I don't want to be
> > > > accountable if something goes wrong in this podling."
> > >
> > > Right, but that same concern could be applied to every single TLP
> > > and yet the board seems to do the right thing with that.
> > >
> > > > Having the IPMC safety net means its at least the IPMC's fault if
> > > something
> > > > goes wrong.
> > >
> > > My point all along has been that this is a false sense of security.
> > >
> > > In fact,
> > > in my opinion it leads to the very unfortunate side effect of IPMC
> > > feeling in need to justify why it exists by micromanaging podlings.
> > >
> > > > Personally, I'd be happy if the PPMCs had more self governance. But
> I
> > > > think there are also some key people on the IPMC that should be able
> to
> > > > lend their skills out to the broader PPMCs in case of need.
> > >
> > > Which would be totally fine and gets us back to the point Daniel and I
> > were
> > > discussing: a release compliance team (horrible name, I know) as part
> of
> > > ASF.
> > >
> > > Thanks,
> > > Roman.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Arvind Prabhakar <ar...@apache.org>.
On Tue, Aug 4, 2015 at 9:15 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> On Mon, Aug 3, 2015, at 07:06 PM, Arvind Prabhakar wrote:
> > That said, I have personally been in positions where I have seen IPMC
> > members ask - and even demand things at times - that I feel are
> > unreasonable requests for the podling. The reason I do not challenge
> > those is because I feel that their asks are rooted in good intentions,
> and that
> > the IPMC in its current form encourages such involvement and authority.
> > At the same time I also worry about the state of the podling and what
> this
> > does to their way of thinking about Apache and the Incubator.
>
> Can you give an example (possibly abstracted to protect the guilty)?
>
Sorry if I implied any guilt/blame here, I don't think there is any really.
I can only relate to my personal experiences as a committer working on
projects that went through Incubation, and also as a mentor/observer of
various other projects going through similar situations. In those
situations, I have struggled with the fine line between desirable vs
required behavior of the podling. Since the distinction is fairly
subjective, and the Incubator is generally inclined towards debate and
empowerment of mentors, the podlings often get caught in the cross-fire.
Further, when there are examples of TLPs that exist without the behavior in
question, it seems hypocritical on the surface - but to me implies that
different communities develop their own micro-cultures that work for them.
I therefore think that it will be far more effective to have a tactical
IPMC that targets the minimal set of processes to be followed by the
podling, and allows it to organically grow itself and it's culture.
Regards,
Arvind Prabhakar
>
> I'm very aware that I don't have as much experience as other folks
> mentoring, and would be grateful if podlings (politely) pushed back if I
> am in fact asking for / demanding anything that is not reasonable.
> Best,
>
> jzb
> --
> Joe Brockmeier
> jzb@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Reform of Incubator {was;
[DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Joe Brockmeier <jz...@zonker.net>.
On Mon, Aug 3, 2015, at 07:06 PM, Arvind Prabhakar wrote:
> That said, I have personally been in positions where I have seen IPMC
> members ask - and even demand things at times - that I feel are
> unreasonable requests for the podling. The reason I do not challenge
> those is because I feel that their asks are rooted in good intentions, and that
> the IPMC in its current form encourages such involvement and authority.
> At the same time I also worry about the state of the podling and what this
> does to their way of thinking about Apache and the Incubator.
Can you give an example (possibly abstracted to protect the guilty)?
I'm very aware that I don't have as much experience as other folks
mentoring, and would be grateful if podlings (politely) pushed back if I
am in fact asking for / demanding anything that is not reasonable.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Arvind Prabhakar <ar...@apache.org>.
On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
>
> In fact, in my opinion it leads to the very unfortunate side effect of IPMC
> >
> feeling in need to justify why it exists by micromanaging podlings.
>
> I've been through incubation as a mentor on Phoenix, Nifi, and now getting
> up to speed on Trafodion, I have not seen micromanagement of podlings.
> Could you point out an example? Curious what you mean.
>
It is worth noting that none of the IPMC members micromanage on purpose, or
are even aware that their actions are being interpreted as acts of
micromanagement. From their perspective, it is their responsibility to
guide the podling, and that is what they are trying to do. It will unfair
to bring those out as examples of micromanagement.
That said, I have personally been in positions where I have seen IPMC
members ask - and even demand things at times - that I feel are
unreasonable requests for the podling. The reason I do not challenge those
is because I feel that their asks are rooted in good intentions, and that
the IPMC in its current form encourages such involvement and authority. At
the same time I also worry about the state of the podling and what this
does to their way of thinking about Apache and the Incubator.
Regards,
Arvind Prabhakar
>
>
> On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament <jo...@apache.org>
> > wrote:
> > > I wonder how much of the silence is a notion of "I don't want to be
> > > accountable if something goes wrong in this podling."
> >
> > Right, but that same concern could be applied to every single TLP
> > and yet the board seems to do the right thing with that.
> >
> > > Having the IPMC safety net means its at least the IPMC's fault if
> > something
> > > goes wrong.
> >
> > My point all along has been that this is a false sense of security.
> >
> > In fact,
> > in my opinion it leads to the very unfortunate side effect of IPMC
> > feeling in need to justify why it exists by micromanaging podlings.
> >
> > > Personally, I'd be happy if the PPMCs had more self governance. But I
> > > think there are also some key people on the IPMC that should be able to
> > > lend their skills out to the broader PPMCs in case of need.
> >
> > Which would be totally fine and gets us back to the point Daniel and I
> were
> > discussing: a release compliance team (horrible name, I know) as part of
> > ASF.
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Andrew Purtell <ap...@apache.org>.
>
In fact, in my opinion it leads to the very unfortunate side effect of IPMC
>
feeling in need to justify why it exists by micromanaging podlings.
I've been through incubation as a mentor on Phoenix, Nifi, and now getting
up to speed on Trafodion, I have not seen micromanagement of podlings.
Could you point out an example? Curious what you mean.
On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament <jo...@apache.org>
> wrote:
> > I wonder how much of the silence is a notion of "I don't want to be
> > accountable if something goes wrong in this podling."
>
> Right, but that same concern could be applied to every single TLP
> and yet the board seems to do the right thing with that.
>
> > Having the IPMC safety net means its at least the IPMC's fault if
> something
> > goes wrong.
>
> My point all along has been that this is a false sense of security.
>
> In fact,
> in my opinion it leads to the very unfortunate side effect of IPMC
> feeling in need to justify why it exists by micromanaging podlings.
>
> > Personally, I'd be happy if the PPMCs had more self governance. But I
> > think there are also some key people on the IPMC that should be able to
> > lend their skills out to the broader PPMCs in case of need.
>
> Which would be totally fine and gets us back to the point Daniel and I were
> discussing: a release compliance team (horrible name, I know) as part of
> ASF.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament <jo...@apache.org> wrote:
> I wonder how much of the silence is a notion of "I don't want to be
> accountable if something goes wrong in this podling."
Right, but that same concern could be applied to every single TLP
and yet the board seems to do the right thing with that.
> Having the IPMC safety net means its at least the IPMC's fault if something
> goes wrong.
My point all along has been that this is a false sense of security. In fact,
in my opinion it leads to the very unfortunate side effect of IPMC
feeling in need to justify why it exists by micromanaging podlings.
> Personally, I'd be happy if the PPMCs had more self governance. But I
> think there are also some key people on the IPMC that should be able to
> lend their skills out to the broader PPMCs in case of need.
Which would be totally fine and gets us back to the point Daniel and I were
discussing: a release compliance team (horrible name, I know) as part of ASF.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by "John D. Ament" <jo...@apache.org>.
I wonder how much of the silence is a notion of "I don't want to be
accountable if something goes wrong in this podling."
Having the IPMC safety net means its at least the IPMC's fault if something
goes wrong.
Personally, I'd be happy if the PPMCs had more self governance. But I
think there are also some key people on the IPMC that should be able to
lend their skills out to the broader PPMCs in case of need.
John
On Sun, Aug 2, 2015 at 10:06 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> I've been waiting for a bout a week for other to chime in, but
> it seems that nobody has so I'll repeat my question as of
> a week ago: what would be the effective way to change the
> status quo around IPMC an make it more board like?
>
> Perhaps we can start from making the release policy actually
> make sense along the lines that Ross has outlined. I guess
> I can propose a change to the current policies (or to Ross'
> point just get it back from the wayback machine :-)).
>
> But seriously, who else thinks the movement towards empowering
> PPMCs and making IPMC very much like the board makes sense?
>
> Thanks,
> Roman.
>
> On Sun, Jul 26, 2015 at 8:56 PM, Ross Gardler
> <Ro...@microsoft.com> wrote:
> > Well this explains how it got this way, it was poorly worded from the
> start...
> >
> > The first part is about incoming code (the SGA) and nothing has changed
> there.
> >
> > The second part says " SHALL formally request the Incubator PMC approve
> such a release" It does not say [VOTE] and it was never, IMHO, intended to
> be a separate vote (unless there were insufficient IPMC votes).
> >
> > Speaking personally I have always (and I know many other mentors have
> also, certainly all those that have co-mentored with me) treated a vote on
> the podling list as binding and a "request" in the form of a notification
> (giving time to object if appropriate) when three positive IPMC votes have
> been cast.
> >
> > In 2006 it said "Therefore, should a Podling decide it wishes to perform
> a release, the Podling SHALL hold a vote on the Podling's public -dev list.
> At least three +1 votes are required (see the Apache Voting Process page),
> and only the PPMC member votes are binding. If the majority of all votes is
> positive, then the Podling SHALL send a summary of that vote to the
> Incubator's general list and formally request the Incubator PMC approve
> such a release."
> >
> > That's still the wording today.
> >
> > I've never been challenged on this approach (having mentored many
> podlings). It was my approach with the most recent release I was a part of,
> just last week (Ripple). The additional reviews received from the IPMC were
> useful, spotting a couple of small items, and turned up the one required +1
> (only two binding mentor votes).
> >
> > Whether this is an accurate recollection of what was discussed way back,
> or whether this is just a practice I (and others) have fallen into and not
> been challenged on I urge the IPMC to consider this approach (of course, it
> does rely on proper oversight from mentors and the IPMC, I'm comfortable
> with this approach because I never vote +1 without having done due
> diligence on the release - I trust others do the same).
> >
> >
> > Ross
> >
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Sunday, July 26, 2015 6:05 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 8:41 PM, Ross Gardler <
> Ross.Gardler@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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Reform of Incubator
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Aug 04, 2015 at 02:50PM, Joe Brockmeier wrote:
> On 08/04/2015 02:45 PM, Konstantin Boudnik wrote:
> > Sorry if it rubs the wrong way. However, we just have seen through the Ignite
> > discussion (most recent one) the examples where personal expectations were
> > represented as graduation requirements. It is perhaps in good faith - I am not
> > questioning the intention. I am saying that when requirements are unclear,
> > people interpret them based on their own understanding of unwritten Apache
> > ethos. As Brane called it earlier - "confusing opinions and policies". You see
> > where I am going with this, right?
>
> Perhaps I'm unclear on the proposal - but how would that be mitigated by
> this proposal? I understand that it might expose podlings to less of
> this when directed towards the full IPMC for graduation, but how would
> it prevent this if a mentor confuses personal expectations for
> graduation requirements?
>
> Isn't that still a potential issue?
You're right, it still might be an issue. My vision was that with a reduced
involvement of the IPMC namely
- IPMC delegating more day-to-day oversight of the podlings to the mentors
- release votes just Cc'ed to general@ instead of an explicit IPMC vote. It
doesn't contradict the requirement of the binding votes, but the primarily
would be coming from mentors, I believe
- more precise graduation guidelines, eg w/o moot 'diversity'-like points
the environment will be less accommodating for such confusions and would cause
lesser number of complex debates. This, in turn, will make the incubation
process more transparent and less counter-intuitive for newcomers.
Hopefully it clarifies my point a bit better. What do you think?
Cos
> I may misunderstand or have lost track of how that's handled in all the
> discussion.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Aug 4, 2015 at 8:50 PM, Joe Brockmeier <jz...@zonker.net> wrote:
> ...I may misunderstand or have lost track of how that's handled in all the
> discussion...
you're not alone - IMO the only way such proposals can work is based
on a concise wiki page that explains the proposal and gives everybody
a single reference about what's being discussed. Long email threads
only work for those who can constantly pay attention to them.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Joe Brockmeier <jz...@zonker.net>.
On 08/04/2015 02:45 PM, Konstantin Boudnik wrote:
> Sorry if it rubs the wrong way. However, we just have seen through the Ignite
> discussion (most recent one) the examples where personal expectations were
> represented as graduation requirements. It is perhaps in good faith - I am not
> questioning the intention. I am saying that when requirements are unclear,
> people interpret them based on their own understanding of unwritten Apache
> ethos. As Brane called it earlier - "confusing opinions and policies". You see
> where I am going with this, right?
Perhaps I'm unclear on the proposal - but how would that be mitigated by
this proposal? I understand that it might expose podlings to less of
this when directed towards the full IPMC for graduation, but how would
it prevent this if a mentor confuses personal expectations for
graduation requirements?
Isn't that still a potential issue?
I may misunderstand or have lost track of how that's handled in all the
discussion.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Konstantin Boudnik <co...@apache.org>.
Sorry if it rubs the wrong way. However, we just have seen through the Ignite
discussion (most recent one) the examples where personal expectations were
represented as graduation requirements. It is perhaps in good faith - I am not
questioning the intention. I am saying that when requirements are unclear,
people interpret them based on their own understanding of unwritten Apache
ethos. As Brane called it earlier - "confusing opinions and policies". You see
where I am going with this, right?
Cos
On Tue, Aug 04, 2015 at 08:56AM, Julian Hyde wrote:
> Cos,
>
> There is no "bureaucratism outbreak". People are not "express[ing]
> their expectations as a law-of-the-land". People are trying, in good
> faith, to make sure that decisions are made consistent with the Apache
> ethos. And before you ask, no, that ethos cannot be written down; it
> has to be interpreted via debate. This is what debate sounds like.
>
> Julian
>
>
> On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
> >> On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
> >> <bd...@apache.org> wrote:
> >> > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >> >> ...who else thinks the movement towards empowering
> >> >> PPMCs and making IPMC very much like the board makes sense?...
> >> >
> >> > How is that different from the status quo where a podling with active
> >> > mentors can have their releases +1ed by their mentors, requiring
> >> > minimal interaction with the IPMC?
> >>
> >> I think it is more of a bias issue. IOW, today it seems that the default bias
> >> of IPMC is to consider itself a final authority (or a gatekeeper) on podling
> >> releases. We need to break that bias and make it so that it is truly a safety
> >> net, rather than a gatekeeper.
> >>
> >> IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
> >> emails, not [VOTE].
> >
> > We perhaps are observing the well known phenomena called self-selection bias
> > [1] And it seems to me that the simplification and better clarification of the
> > incubation guidelines might be exactly what's needed to prevent a
> > bureaucratism outbreak. As well as the situation when ppl express their
> > expectations as a law-of-the-land (even from best intentions).
> >
> > Cos
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1
-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com]
Sent: Monday, August 3, 2015 09:37
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
[ ... ]
It's not the central Incubator folks like our regular release
reviewers and report contributors who invent these extra criteria --
it's individual Mentors out on the podling lists. Inaccuracy and
overreach on general@incubator is self-correcting, precisely because
this is where everyone comes together. When inaccuracy and overreach
out on individual podling dev lists, whether that gets corrected
depends on whether the podling is fortunate enough to have a
well-rounded collection of active Mentors.
[ ... ]
The objective of establishing clear policy documentation is certainly
not going to be made any easier by atomizing the Incubator. Instead,
Mentors who have strong opinions and strong personalities will
entrench provincial points of view in the podlings they oversee. When
we finally come together, it will be that much more painful to
establish consensus, whether that is to discuss policy on
general@incubator or legal-discuss@apache, or when the Board comes
into conflict with a TLP that received bad advice as a podling.
As someone who has worked hard building consensus for policy
documentation at Apache, and who has seen that hard work pay off when
Incubator threads which would have been contended several years ago
are now settled quickly, I certainly agree that documenting clear
objective criteria is valuable. But nothing about the present makeup
of the Incubator gets in the way of pursuing that objective -- it's
the opposite. Its because we resolve our differences in small amounts
here that we do not end up as irreconcilable factions later.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Branko Čibej <br...@apache.org>.
On 03.08.2015 18:36, Marvin Humphrey wrote:
> It's not the central Incubator folks like our regular release
> reviewers and report contributors who invent these extra criteria
Sorry but this has to be said: I see folks on this list inventing policy
(or rather, confusing opinion and policy) all the time. The Ignite
graduation discussion was a good example of that, but by no means unique.
It's this micromanagement self-preservation reflex (thanks, Roman!) that
puts me squarely on the side of a smaller IPMC that would hopefully also
be less of a peanut gallery. No offence meant and especially not to the
people who do put in a stellar performance hereabouts.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Aug 3, 2015 at 8:48 AM, Arvind Prabhakar <ar...@apache.org> wrote:
> On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz <bdelacretaz@apache.org
>> wrote:
>
>> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org>
>> wrote:
>> > ...who else thinks the movement towards empowering
>> > PPMCs and making IPMC very much like the board makes sense?...
>>
>> How is that different from the status quo where a podling with active
>> mentors can have their releases +1ed by their mentors, requiring
>> minimal interaction with the IPMC?
>>
>
> In spirit it may not be very different, but in practice it is the polar
> opposite. As someone who has worked through the incubation of a few
> projects both as an initial committer as well as a mentor, I feel that the
> biggest weakness of the current Incubator is it's very strength of being
> all inclusive of different interpretations/understandings of the goals of
> incubation. With every IPMC member having their own close-to-heart issues
> and inclinations, along with their good intentions, I don't think we are
> doing very much to help the podlings understand the principals of Apache
> Way or learn self-governance that works best for their communities.
> Instead, we often end up prescribing things which go beyond the charter of
> the Incubator, just to establish a sense of comfort in ensuring we have met
> our responsibilities.
It's not the central Incubator folks like our regular release
reviewers and report contributors who invent these extra criteria --
it's individual Mentors out on the podling lists. Inaccuracy and
overreach on general@incubator is self-correcting, precisely because
this is where everyone comes together. When inaccuracy and overreach
out on individual podling dev lists, whether that gets corrected
depends on whether the podling is fortunate enough to have a
well-rounded collection of active Mentors.
> Therefore, I too favor the idea of a smaller, well-defined, tactical IPMC
> that:
> a) establishes a clear objective criteria for growth and graduation
> including the necessary processes and policies,
The objective of establishing clear policy documentation is certainly
not going to be made any easier by atomizing the Incubator. Instead,
Mentors who have strong opinions and strong personalities will
entrench provincial points of view in the podlings they oversee. When
we finally come together, it will be that much more painful to
establish consensus, whether that is to discuss policy on
general@incubator or legal-discuss@apache, or when the Board comes
into conflict with a TLP that received bad advice as a podling.
As someone who has worked hard building consensus for policy
documentation at Apache, and who has seen that hard work pay off when
Incubator threads which would have been contended several years ago
are now settled quickly, I certainly agree that documenting clear
objective criteria is valuable. But nothing about the present makeup
of the Incubator gets in the way of pursuing that objective -- it's
the opposite. Its because we resolve our differences in small amounts
here that we do not end up as irreconcilable factions later.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Arvind Prabhakar <ar...@apache.org>.
On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > ...who else thinks the movement towards empowering
> > PPMCs and making IPMC very much like the board makes sense?...
>
> How is that different from the status quo where a podling with active
> mentors can have their releases +1ed by their mentors, requiring
> minimal interaction with the IPMC?
>
In spirit it may not be very different, but in practice it is the polar
opposite. As someone who has worked through the incubation of a few
projects both as an initial committer as well as a mentor, I feel that the
biggest weakness of the current Incubator is it's very strength of being
all inclusive of different interpretations/understandings of the goals of
incubation. With every IPMC member having their own close-to-heart issues
and inclinations, along with their good intentions, I don't think we are
doing very much to help the podlings understand the principals of Apache
Way or learn self-governance that works best for their communities.
Instead, we often end up prescribing things which go beyond the charter of
the Incubator, just to establish a sense of comfort in ensuring we have met
our responsibilities.
Therefore, I too favor the idea of a smaller, well-defined, tactical IPMC
that:
a) establishes a clear objective criteria for growth and graduation
including the necessary processes and policies,
b) oversees the execution of these processes and policies via measurable
means, and,
c) has the final say in the graduation of the podling
...will be a big step in the right direction. This does look more like the
way our board is organized. Arguably, this IPMC could still enlist the help
of member/mentors but will be doing so without granting the decision making
privileges to them.
Regards,
Arvind Prabhakar
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-08-03 09:37, Bertrand Delacretaz wrote:
> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> ...who else thinks the movement towards empowering
>> PPMCs and making IPMC very much like the board makes sense?...
> How is that different from the status quo where a podling with active
> mentors can have their releases +1ed by their mentors, requiring
> minimal interaction with the IPMC?
>
As you say, releases can - if done right - be done with minimal friction
from the IPMC, so the issue seems more to be an issue of perception and
procedure than an issue of policy. There is a clear distinction between
how the board acts towards TLPs and how the IPMC acts towards podlings,
and in my opinion there should be: TLPs are _expected to know how to
act, how to release, how to self-govern_. They have learned this through
trial and error, many of them in the Incubator, and have built up
procedures and cultures that enable them to (mostly) govern themselves.
Podlings are _in training to be like that_, and even with 4, 5, 6
mentors, it has been shown time and time again (as I believe Marvin also
mentioned), that there will be issues with the first one or two
releases, as is only natural when a project is learning how to do
Apache-style releases, and then the IPMC says "hang on, you need to do
these things differently, fix this, that, and then do this", and then
the podling slowly adapts to the way we do releases. As we continue to
let in more and more podlings, it is also safe to assume, that the
number of 'initial release bugs' will increase, thus this system becomes
even more important.
To sum up my view: We have a release process that has shown many times
that it both works and is necessary for podlings, especially on the
first release. I think this is awesome, and I don't see the need to
change this specific policy - *but perhaps we could ease the process, as
I suggested last week, through better tooling and education.*
Allow me to also ask this question: If there is a _visible_ need for
this existing policy, as has been shown on numerous occasions, how is
empowering PPMCs by removing the policy going to solve or help the
issue? I am all for a hands-off approach if it leads to a desired goal
(wholly or partially), but this specific proposition seems to be
counter-intuitive to me.
Therefore, I will suggest the same thing I did last week:
- Keep the existing policy
- Make better processes and tooling to aid podlings in their first
release(s) (see my previous email for details)
- Consider a mentor rotation/swap-in principle to ensure a fresh
unbiased/non-myopic governance.
Heck, I'd even, to some degree, recommend these steps for TLPs, but eh,
that's another story :)
If we can create procedures and tools that can do most of the basic
legal and structural checks in new release candidates, we could cut down
the time spent arguing about the nitty gritty details, and a lot of the
unfortunate situations where a podling needs to release fast, but gets
caught in a legal issue, could be avoided or at the very least be
resolved a lot faster.
With regards,
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Julian Hyde <jh...@apache.org>.
Cos,
There is no "bureaucratism outbreak". People are not "express[ing]
their expectations as a law-of-the-land". People are trying, in good
faith, to make sure that decisions are made consistent with the Apache
ethos. And before you ask, no, that ethos cannot be written down; it
has to be interpreted via debate. This is what debate sounds like.
Julian
On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik <co...@apache.org> wrote:
> On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
>> On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>> > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> >> ...who else thinks the movement towards empowering
>> >> PPMCs and making IPMC very much like the board makes sense?...
>> >
>> > How is that different from the status quo where a podling with active
>> > mentors can have their releases +1ed by their mentors, requiring
>> > minimal interaction with the IPMC?
>>
>> I think it is more of a bias issue. IOW, today it seems that the default bias
>> of IPMC is to consider itself a final authority (or a gatekeeper) on podling
>> releases. We need to break that bias and make it so that it is truly a safety
>> net, rather than a gatekeeper.
>>
>> IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
>> emails, not [VOTE].
>
> We perhaps are observing the well known phenomena called self-selection bias
> [1] And it seems to me that the simplification and better clarification of the
> incubation guidelines might be exactly what's needed to prevent a
> bureaucratism outbreak. As well as the situation when ppl express their
> expectations as a law-of-the-land (even from best intentions).
>
> Cos
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
> On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >> ...who else thinks the movement towards empowering
> >> PPMCs and making IPMC very much like the board makes sense?...
> >
> > How is that different from the status quo where a podling with active
> > mentors can have their releases +1ed by their mentors, requiring
> > minimal interaction with the IPMC?
>
> I think it is more of a bias issue. IOW, today it seems that the default bias
> of IPMC is to consider itself a final authority (or a gatekeeper) on podling
> releases. We need to break that bias and make it so that it is truly a safety
> net, rather than a gatekeeper.
>
> IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
> emails, not [VOTE].
We perhaps are observing the well known phenomena called self-selection bias
[1] And it seems to me that the simplification and better clarification of the
incubation guidelines might be exactly what's needed to prevent a
bureaucratism outbreak. As well as the situation when ppl express their
expectations as a law-of-the-land (even from best intentions).
Cos
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>> ...who else thinks the movement towards empowering
>> PPMCs and making IPMC very much like the board makes sense?...
>
> How is that different from the status quo where a podling with active
> mentors can have their releases +1ed by their mentors, requiring
> minimal interaction with the IPMC?
I think it is more of a bias issue. IOW, today it seems that the default bias
of IPMC is to consider itself a final authority (or a gatekeeper) on podling
releases. We need to break that bias and make it so that it is truly a safety
net, rather than a gatekeeper.
IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
emails, not [VOTE].
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> ...who else thinks the movement towards empowering
> PPMCs and making IPMC very much like the board makes sense?...
How is that different from the status quo where a podling with active
mentors can have their releases +1ed by their mentors, requiring
minimal interaction with the IPMC?
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Aug 2, 2015 at 7:05 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> what would be the effective way to change the
> status quo around IPMC an make it more board like?
The Board works very hard to provide thorough review of the reports it
receives. While IPMC review of podling reports is better than it used
to be, there is still room for improvement, particularly in the realm
of cross-cutting feedback.
> Perhaps we can start from making the release policy actually
> make sense along the lines that Ross has outlined. I guess
> I can propose a change to the current policies (or to Ross'
> point just get it back from the wayback machine :-)).
We worked hard to improve the situation around releasing and we
succeeded. The Incubator today produces higher quality releases more
efficiently and with less contention than it ever has before.
To address the specific point about voting, there have been a number
of times when release votes are run simultaneously on the podling dev
list and general@incubator. It's fine. I tend not to recommend it
simply because most podlings screw up RC release mechanics a lot and
going through several trivial RCs adds noise to general@incubator.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was;
[DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Joe Brockmeier <jz...@zonker.net>.
On Tue, Aug 4, 2015, at 12:23 PM, Ross Gardler wrote:
> It's hard to get the balance right between appropriate oversight and
> unwanted meddling.
No argument there. I'm unconvinced that a restructuring of the
IPMC/PPMC/Mentorship structure as it is today will solve that, though it
might push it around a little.
I do think negotiating/communicating with mentors is a skill that helps
folks deal with building community and running a project - which is
often new to folks coming to the Incubator. So if there's "unwanted
meddling" I hope that folks are able to push back a little bit and
resolve that without having to throw out (a potentially) reasonable
structure just to get around it.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
Since I +1d Romans comment I also want to draw attention to your valuable observation on the topic:
"A lot of companies seem to view any friction (e.g. "actually complying
with policies that put community over code") as "political overhead"
that makes joining the foundation undesirable. "
+1 to that also.
I think it becomes a problem when people come out of the woodwork at a critical point in a puddings
Podlings lifecycle (e.g. Releases, graduation) with minutia and/or an on the fly reinterpretation of policy.
It's hard to get the balance right between appropriate oversight and unwanted meddling.
Sent from my Windows Phone
________________________________
From: Joe Brockmeier<ma...@zonker.net>
Sent: 8/4/2015 9:16 AM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015, at 03:13 PM, Roman Shaposhnik wrote:
> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> > On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
> >> I've been waiting for a bout a week for other to chime in, but
> >> it seems that nobody has so I'll repeat my question as of
> >> a week ago: what would be the effective way to change the
> >> status quo around IPMC an make it more board like?
> >>
> >> Perhaps we can start from making the release policy actually
> >> make sense along the lines that Ross has outlined. I guess
> >> I can propose a change to the current policies (or to Ross'
> >> point just get it back from the wayback machine :-)).
> >>
> >> But seriously, who else thinks the movement towards empowering
> >> PPMCs and making IPMC very much like the board makes sense?
> >
> > I think the thread fizzled because there's not a lot of support for the
> > idea. At least, on my end, I'm not in favor.
>
> Yup. I believe this to be an unfortunate (at least from my standpoint)
> but and extremely fair observation.
>
> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
> stalemate right now. We clearly have a "everything's fine lets just
> add more policy" constituency vs. "IPMC should be small and more
> board like" crowd.
If I had to identify one problem that the IPMC/Incubator suffers from at
the moment it would not be a need for a "small and more board like"
structure. The biggest problem (and perhaps I view it this way because
I'm suffering from it / am part of the problem) is a lack of time /
attention from mentors. I'm really not sure that the proposal here
solves that in any meaningful way.
> The good news is that we're all united on making sure that the foundation
> is growing by podlings making progress and graduating to TLPs. The
> bad news is that because of the current mentality I don't see the types
> of unfortunate threads that Ignite just went through going away anytime
> soon.
What about the Ignite thread was "unfortunate"? That it was a bit heated
at times, or just the fact that there was disagreement?
I fear that there's too much bias towards +1'ing things even when folks
have legitimate concerns.
> This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation. Which is
> grossly unfair at the board level, but unfortunately seems to be very
> true at IPMC level today.
A lot of companies seem to view any friction (e.g. "actually complying
with policies that put community over code") as "political overhead"
that makes joining the foundation undesirable.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator
Posted by Niall Pemberton <ni...@gmail.com>.
On Tue, Aug 11, 2015 at 9:27 PM, Branko Čibej <br...@apache.org> wrote:
> On 04.08.2015 18:12, Joe Brockmeier wrote:
> > What about the Ignite thread was "unfortunate"? That it was a bit
> > heated at times, or just the fact that there was disagreement? I fear
> > that there's too much bias towards +1'ing things even when folks have
> > legitimate concerns.
>
>
> Heated and disagreement are not a problem. The problem I see are all the
> people who know nothing about the day-to-day life of the podling, then
> start stating conditions for their graduation votes that have nothing to
> do with either published ASF policy or published Incubator guidelines.
> I'm not going to state names but it's fairly obvious from the archives
> who I'm talking about.
>
> This kind of behaviour not only wastes time but puts mentors in an
> impossible position: on the one hand, we have to sink a lot of time into
> guiding the podling (sometimes with a cluebat), and on the other we have
> to defend the podling and our own integrity from the peanut gallery.
>
I can't see what the problem is with the discussion over the Ignite
graduation. Seems to me the podling took away some positive actions from
that debate and at the end of the day they still graduated. So best of both
worlds. Going to a model where only the mentors get to say anything to the
podling would mean they would have missed out on that. Its not the Ignites
that worry me (because they seemed like a clued up community) - but more
projects that are less than proactive about embracing how ASF projects
should work combined with mentors that are not so engaged - we could end up
with a rubber stamped graduation of a project not working how it should.
Niall
> No wonder there are never enough active mentors to go around; who in
> their right mind would want to spend their free time to go through this
> rigmarole twice?
>
> -- Brane
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Reform of Incubator
Posted by Branko Čibej <br...@apache.org>.
On 04.08.2015 18:12, Joe Brockmeier wrote:
> What about the Ignite thread was "unfortunate"? That it was a bit
> heated at times, or just the fact that there was disagreement? I fear
> that there's too much bias towards +1'ing things even when folks have
> legitimate concerns.
Heated and disagreement are not a problem. The problem I see are all the
people who know nothing about the day-to-day life of the podling, then
start stating conditions for their graduation votes that have nothing to
do with either published ASF policy or published Incubator guidelines.
I'm not going to state names but it's fairly obvious from the archives
who I'm talking about.
This kind of behaviour not only wastes time but puts mentors in an
impossible position: on the one hand, we have to sink a lot of time into
guiding the podling (sometimes with a cluebat), and on the other we have
to defend the podling and our own integrity from the peanut gallery.
No wonder there are never enough active mentors to go around; who in
their right mind would want to spend their free time to go through this
rigmarole twice?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was;
[DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Joe Brockmeier <jz...@zonker.net>.
On Mon, Aug 3, 2015, at 03:13 PM, Roman Shaposhnik wrote:
> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> > On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
> >> I've been waiting for a bout a week for other to chime in, but
> >> it seems that nobody has so I'll repeat my question as of
> >> a week ago: what would be the effective way to change the
> >> status quo around IPMC an make it more board like?
> >>
> >> Perhaps we can start from making the release policy actually
> >> make sense along the lines that Ross has outlined. I guess
> >> I can propose a change to the current policies (or to Ross'
> >> point just get it back from the wayback machine :-)).
> >>
> >> But seriously, who else thinks the movement towards empowering
> >> PPMCs and making IPMC very much like the board makes sense?
> >
> > I think the thread fizzled because there's not a lot of support for the
> > idea. At least, on my end, I'm not in favor.
>
> Yup. I believe this to be an unfortunate (at least from my standpoint)
> but and extremely fair observation.
>
> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
> stalemate right now. We clearly have a "everything's fine lets just
> add more policy" constituency vs. "IPMC should be small and more
> board like" crowd.
If I had to identify one problem that the IPMC/Incubator suffers from at
the moment it would not be a need for a "small and more board like"
structure. The biggest problem (and perhaps I view it this way because
I'm suffering from it / am part of the problem) is a lack of time /
attention from mentors. I'm really not sure that the proposal here
solves that in any meaningful way.
> The good news is that we're all united on making sure that the foundation
> is growing by podlings making progress and graduating to TLPs. The
> bad news is that because of the current mentality I don't see the types
> of unfortunate threads that Ignite just went through going away anytime
> soon.
What about the Ignite thread was "unfortunate"? That it was a bit heated
at times, or just the fact that there was disagreement?
I fear that there's too much bias towards +1'ing things even when folks
have legitimate concerns.
> This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation. Which is
> grossly unfair at the board level, but unfortunately seems to be very
> true at IPMC level today.
A lot of companies seem to view any friction (e.g. "actually complying
with policies that put community over code") as "political overhead"
that makes joining the foundation undesirable.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-08-03 21:13, Roman Shaposhnik wrote:
> Yup. I believe this to be an unfortunate (at least from my standpoint)
> but and extremely fair observation.
>
> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
> stalemate right now. We clearly have a "everything's fine lets just
> add more policy" constituency vs. "IPMC should be small and more
> board like" crowd.
>
I don't think anyone is suggesting we add more policy - at least, I
haven't heard anyone say that. I'd rather say we're caught between "the
policy is fine, but we may need to streamline the process" and "the
policy is hindering development and needs to be trimmed".
I count myself among the 'followers' of the first statement. I think the
policy itself is sound, but the process of incubation leaves something
to be desired. In my view, if a release, graduation, vote etc is being
held up by the IPMC, that is not the fault of the policy, it is the
fault of tacit knowledge not being shared and used among mentors and
podlings in an efficient manner. If a release is being held up due to
missing/incorrect licenses or notices, that is an issue we should solve
through better education and tooling in the Incubator. If a podling
wants to graduate, but legitimate concerns (however true or unfounded
they may be) are raised, that is an issue we should solve - or at least
make speedier - through better education and tooling/processes.
I see a lot of places where we can definitely improve on processes, make
them faster and easier, but what I do not see is how the policies are to
blame. The very fact that these policies cause discussions and delays
are, in my view, not a nuisance that needs to be abolished, but proof
that we have procedural and educational flaws. Again, I would be very
interested in working with people on improving these processes and tools.
I would also ask the people who think we need to trim down our policies
to be more specific about which policies need to be removed or changed,
and how it would help the Incubator while still retaining the core
mission of it; To educate and grow communities wishing to follow the
Apache Way.
With regards,
Daniel.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Andrew Purtell <ap...@apache.org>.
Who are the village spinsters?
On Mon, Aug 3, 2015 at 1:21 PM, Branko Čibej <br...@apache.org> wrote:
> On 03.08.2015 21:51, Julian Hyde wrote:
> > In my experience incubating Calcite, the “overhead” was mostly the
> infrastructure and process, not politics. (If you think the incubator is
> political, you haven’t seen politics…) The process is necessary (mostly) to
> ensure clean IP. The infrastructure, less so. So, if we’re talking about
> how to reduce the burden on podlings, those are the areas I would focus on.
> >
> > Roman’s proposed reform places more responsibility on podling PMCs and,
> by implication, the mentors embedded in those PMCs.
>
> At the end of the day, it *is* the mentors' responsibility. The IPMC
> mostly gets involved after the fact.
>
> > I am not sure how well that would work in practice given the ongoing
> problem of absentee mentors. The IPMC epitomizes the “it takes a village to
> raise a child”, in particular with village elders stepping in with
> help/advice from time to time. It would be a shame to lose that.
>
> There's no need to lose that. But it would be a really good idea to lose
> the village spinster who makes the child afraid of the dark and monsters
> under the bed ...
>
> -- Brane
>
>
> >> On Aug 3, 2015, at 12:23 PM, Ross Gardler <Ro...@microsoft.com>
> wrote:
> >>
> >> " This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation.
> Which is grossly unfair at the board level, but unfortunately seems to be
> very true at IPMC level today."
> >>
> >> +1000
> >>
> >> -----Original Message-----
> >> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of
> Roman Shaposhnik
> >> Sent: Monday, August 3, 2015 12:13 PM
> >> To: general@incubator.apache.org
> >> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite
> from the Apache Incubator)
> >>
> >> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> >>> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
> >>>> I've been waiting for a bout a week for other to chime in, but it
> >>>> seems that nobody has so I'll repeat my question as of a week ago:
> >>>> what would be the effective way to change the status quo around IPMC
> >>>> an make it more board like?
> >>>>
> >>>> Perhaps we can start from making the release policy actually make
> >>>> sense along the lines that Ross has outlined. I guess I can propose a
> >>>> change to the current policies (or to Ross'
> >>>> point just get it back from the wayback machine :-)).
> >>>>
> >>>> But seriously, who else thinks the movement towards empowering PPMCs
> >>>> and making IPMC very much like the board makes sense?
> >>> I think the thread fizzled because there's not a lot of support for
> >>> the idea. At least, on my end, I'm not in favor.
> >> Yup. I believe this to be an unfortunate (at least from my standpoint)
> but and extremely fair observation.
> >>
> >> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
> stalemate right now. We clearly have a "everything's fine lets just add
> more policy" constituency vs. "IPMC should be small and more board like"
> crowd.
> >>
> >> The good news is that we're all united on making sure that the
> foundation is growing by podlings making progress and graduating to TLPs.
> The bad news is that because of the current mentality I don't see the types
> of unfortunate threads that Ignite just went through going away anytime
> soon.
> >>
> >> This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation.
> Which is grossly unfair at the board level, but unfortunately seems to be
> very true at IPMC level today.
> >>
> >> It is clear to me that the change has very little chance of coming from
> within IPMC.
> >>
> >> Thanks,
> >> Roman.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Branko Čibej <br...@apache.org>.
On 03.08.2015 21:51, Julian Hyde wrote:
> In my experience incubating Calcite, the “overhead” was mostly the infrastructure and process, not politics. (If you think the incubator is political, you haven’t seen politics…) The process is necessary (mostly) to ensure clean IP. The infrastructure, less so. So, if we’re talking about how to reduce the burden on podlings, those are the areas I would focus on.
>
> Roman’s proposed reform places more responsibility on podling PMCs and, by implication, the mentors embedded in those PMCs.
At the end of the day, it *is* the mentors' responsibility. The IPMC
mostly gets involved after the fact.
> I am not sure how well that would work in practice given the ongoing problem of absentee mentors. The IPMC epitomizes the “it takes a village to raise a child”, in particular with village elders stepping in with help/advice from time to time. It would be a shame to lose that.
There's no need to lose that. But it would be a really good idea to lose
the village spinster who makes the child afraid of the dark and monsters
under the bed ...
-- Brane
>> On Aug 3, 2015, at 12:23 PM, Ross Gardler <Ro...@microsoft.com> wrote:
>>
>> " This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today."
>>
>> +1000
>>
>> -----Original Message-----
>> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
>> Sent: Monday, August 3, 2015 12:13 PM
>> To: general@incubator.apache.org
>> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
>>
>> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
>>> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>>>> I've been waiting for a bout a week for other to chime in, but it
>>>> seems that nobody has so I'll repeat my question as of a week ago:
>>>> what would be the effective way to change the status quo around IPMC
>>>> an make it more board like?
>>>>
>>>> Perhaps we can start from making the release policy actually make
>>>> sense along the lines that Ross has outlined. I guess I can propose a
>>>> change to the current policies (or to Ross'
>>>> point just get it back from the wayback machine :-)).
>>>>
>>>> But seriously, who else thinks the movement towards empowering PPMCs
>>>> and making IPMC very much like the board makes sense?
>>> I think the thread fizzled because there's not a lot of support for
>>> the idea. At least, on my end, I'm not in favor.
>> Yup. I believe this to be an unfortunate (at least from my standpoint) but and extremely fair observation.
>>
>> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a stalemate right now. We clearly have a "everything's fine lets just add more policy" constituency vs. "IPMC should be small and more board like" crowd.
>>
>> The good news is that we're all united on making sure that the foundation is growing by podlings making progress and graduating to TLPs. The bad news is that because of the current mentality I don't see the types of unfortunate threads that Ignite just went through going away anytime soon.
>>
>> This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today.
>>
>> It is clear to me that the change has very little chance of coming from within IPMC.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Andy Seaborne <an...@apache.org>.
+1
I haven't experienced micromanagement as a mentor. Quite the opposite.
If it all comes down the mentors and with the AWOL rate the mentoring
can become a very few opinions. I think tegher is an implicit
assumption of experienced mentors here.
If more is pushed down to the mentors, I've have to think carefully
about mentoring. Both the increased expectations and the increased need
to be available at certain times. I personally would not feel I could
mentor any podling that wasn't similar in structure to some TLP I'm
involved in. Otherwise I simply haven't the breadth of experience to be
useful and could become hindrance/danger.
Bootstrap requires a burst of time and it's quite important to get that
streamlined. The core of L&N could be made more algorithmic for many
podlings.
Andy
On 03/08/15 20:51, Julian Hyde wrote:
> In my experience incubating Calcite, the “overhead” was mostly the infrastructure and process, not politics. (If you think the incubator is political, you haven’t seen politics…) The process is necessary (mostly) to ensure clean IP. The infrastructure, less so. So, if we’re talking about how to reduce the burden on podlings, those are the areas I would focus on.
>
> Roman’s proposed reform places more responsibility on podling PMCs and, by implication, the mentors embedded in those PMCs. I am not sure how well that would work in practice given the ongoing problem of absentee mentors. The IPMC epitomizes the “it takes a village to raise a child”, in particular with village elders stepping in with help/advice from time to time. It would be a shame to lose that.
>
> Julian
>
>
>> On Aug 3, 2015, at 12:23 PM, Ross Gardler <Ro...@microsoft.com> wrote:
>>
>> " This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today."
>>
>> +1000
>>
>> -----Original Message-----
>> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
>> Sent: Monday, August 3, 2015 12:13 PM
>> To: general@incubator.apache.org
>> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
>>
>> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
>>> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>>>> I've been waiting for a bout a week for other to chime in, but it
>>>> seems that nobody has so I'll repeat my question as of a week ago:
>>>> what would be the effective way to change the status quo around IPMC
>>>> an make it more board like?
>>>>
>>>> Perhaps we can start from making the release policy actually make
>>>> sense along the lines that Ross has outlined. I guess I can propose a
>>>> change to the current policies (or to Ross'
>>>> point just get it back from the wayback machine :-)).
>>>>
>>>> But seriously, who else thinks the movement towards empowering PPMCs
>>>> and making IPMC very much like the board makes sense?
>>>
>>> I think the thread fizzled because there's not a lot of support for
>>> the idea. At least, on my end, I'm not in favor.
>>
>> Yup. I believe this to be an unfortunate (at least from my standpoint) but and extremely fair observation.
>>
>> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a stalemate right now. We clearly have a "everything's fine lets just add more policy" constituency vs. "IPMC should be small and more board like" crowd.
>>
>> The good news is that we're all united on making sure that the foundation is growing by podlings making progress and graduating to TLPs. The bad news is that because of the current mentality I don't see the types of unfortunate threads that Ignite just went through going away anytime soon.
>>
>> This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today.
>>
>> It is clear to me that the change has very little chance of coming from within IPMC.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Julian Hyde <jh...@apache.org>.
In my experience incubating Calcite, the “overhead” was mostly the infrastructure and process, not politics. (If you think the incubator is political, you haven’t seen politics…) The process is necessary (mostly) to ensure clean IP. The infrastructure, less so. So, if we’re talking about how to reduce the burden on podlings, those are the areas I would focus on.
Roman’s proposed reform places more responsibility on podling PMCs and, by implication, the mentors embedded in those PMCs. I am not sure how well that would work in practice given the ongoing problem of absentee mentors. The IPMC epitomizes the “it takes a village to raise a child”, in particular with village elders stepping in with help/advice from time to time. It would be a shame to lose that.
Julian
> On Aug 3, 2015, at 12:23 PM, Ross Gardler <Ro...@microsoft.com> wrote:
>
> " This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today."
>
> +1000
>
> -----Original Message-----
> From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
> Sent: Monday, August 3, 2015 12:13 PM
> To: general@incubator.apache.org
> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
>
> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
>> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>>> I've been waiting for a bout a week for other to chime in, but it
>>> seems that nobody has so I'll repeat my question as of a week ago:
>>> what would be the effective way to change the status quo around IPMC
>>> an make it more board like?
>>>
>>> Perhaps we can start from making the release policy actually make
>>> sense along the lines that Ross has outlined. I guess I can propose a
>>> change to the current policies (or to Ross'
>>> point just get it back from the wayback machine :-)).
>>>
>>> But seriously, who else thinks the movement towards empowering PPMCs
>>> and making IPMC very much like the board makes sense?
>>
>> I think the thread fizzled because there's not a lot of support for
>> the idea. At least, on my end, I'm not in favor.
>
> Yup. I believe this to be an unfortunate (at least from my standpoint) but and extremely fair observation.
>
> As far as I'm concerned the issue of R&Rs of IPMC is in a state of a stalemate right now. We clearly have a "everything's fine lets just add more policy" constituency vs. "IPMC should be small and more board like" crowd.
>
> The good news is that we're all united on making sure that the foundation is growing by podlings making progress and graduating to TLPs. The bad news is that because of the current mentality I don't see the types of unfortunate threads that Ignite just went through going away anytime soon.
>
> This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today.
>
> It is clear to me that the change has very little chance of coming from within IPMC.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
" This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today."
+1000
-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Monday, August 3, 2015 12:13 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>> I've been waiting for a bout a week for other to chime in, but it
>> seems that nobody has so I'll repeat my question as of a week ago:
>> what would be the effective way to change the status quo around IPMC
>> an make it more board like?
>>
>> Perhaps we can start from making the release policy actually make
>> sense along the lines that Ross has outlined. I guess I can propose a
>> change to the current policies (or to Ross'
>> point just get it back from the wayback machine :-)).
>>
>> But seriously, who else thinks the movement towards empowering PPMCs
>> and making IPMC very much like the board makes sense?
>
> I think the thread fizzled because there's not a lot of support for
> the idea. At least, on my end, I'm not in favor.
Yup. I believe this to be an unfortunate (at least from my standpoint) but and extremely fair observation.
As far as I'm concerned the issue of R&Rs of IPMC is in a state of a stalemate right now. We clearly have a "everything's fine lets just add more policy" constituency vs. "IPMC should be small and more board like" crowd.
The good news is that we're all united on making sure that the foundation is growing by podlings making progress and graduating to TLPs. The bad news is that because of the current mentality I don't see the types of unfortunate threads that Ignite just went through going away anytime soon.
This is that proverbial "political overhead" that a lot of folks are accusing ASF of and cite as a reason of not going into the foundation. Which is grossly unfair at the board level, but unfortunately seems to be very true at IPMC level today.
It is clear to me that the change has very little chance of coming from within IPMC.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier <jz...@zonker.net> wrote:
> On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
>> I've been waiting for a bout a week for other to chime in, but
>> it seems that nobody has so I'll repeat my question as of
>> a week ago: what would be the effective way to change the
>> status quo around IPMC an make it more board like?
>>
>> Perhaps we can start from making the release policy actually
>> make sense along the lines that Ross has outlined. I guess
>> I can propose a change to the current policies (or to Ross'
>> point just get it back from the wayback machine :-)).
>>
>> But seriously, who else thinks the movement towards empowering
>> PPMCs and making IPMC very much like the board makes sense?
>
> I think the thread fizzled because there's not a lot of support for the
> idea. At least, on my end, I'm not in favor.
Yup. I believe this to be an unfortunate (at least from my standpoint)
but and extremely fair observation.
As far as I'm concerned the issue of R&Rs of IPMC is in a state of a
stalemate right now. We clearly have a "everything's fine lets just
add more policy" constituency vs. "IPMC should be small and more
board like" crowd.
The good news is that we're all united on making sure that the foundation
is growing by podlings making progress and graduating to TLPs. The
bad news is that because of the current mentality I don't see the types
of unfortunate threads that Ignite just went through going away anytime
soon.
This is that proverbial "political overhead" that a lot of folks are accusing
ASF of and cite as a reason of not going into the foundation. Which is
grossly unfair at the board level, but unfortunately seems to be very
true at IPMC level today.
It is clear to me that the change has very little chance of coming from
within IPMC.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was;
[DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Joe Brockmeier <jz...@zonker.net>.
On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
> I've been waiting for a bout a week for other to chime in, but
> it seems that nobody has so I'll repeat my question as of
> a week ago: what would be the effective way to change the
> status quo around IPMC an make it more board like?
>
> Perhaps we can start from making the release policy actually
> make sense along the lines that Ross has outlined. I guess
> I can propose a change to the current policies (or to Ross'
> point just get it back from the wayback machine :-)).
>
> But seriously, who else thinks the movement towards empowering
> PPMCs and making IPMC very much like the board makes sense?
I think the thread fizzled because there's not a lot of support for the
idea. At least, on my end, I'm not in favor.
Best,
jzb
--
Joe Brockmeier
jzb@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
I've been waiting for a bout a week for other to chime in, but
it seems that nobody has so I'll repeat my question as of
a week ago: what would be the effective way to change the
status quo around IPMC an make it more board like?
Perhaps we can start from making the release policy actually
make sense along the lines that Ross has outlined. I guess
I can propose a change to the current policies (or to Ross'
point just get it back from the wayback machine :-)).
But seriously, who else thinks the movement towards empowering
PPMCs and making IPMC very much like the board makes sense?
Thanks,
Roman.
On Sun, Jul 26, 2015 at 8:56 PM, Ross Gardler
<Ro...@microsoft.com> wrote:
> Well this explains how it got this way, it was poorly worded from the start...
>
> The first part is about incoming code (the SGA) and nothing has changed there.
>
> The second part says " SHALL formally request the Incubator PMC approve such a release" It does not say [VOTE] and it was never, IMHO, intended to be a separate vote (unless there were insufficient IPMC votes).
>
> Speaking personally I have always (and I know many other mentors have also, certainly all those that have co-mentored with me) treated a vote on the podling list as binding and a "request" in the form of a notification (giving time to object if appropriate) when three positive IPMC votes have been cast.
>
> In 2006 it said "Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL hold a vote on the Podling's public -dev list. At least three +1 votes are required (see the Apache Voting Process page), and only the PPMC member votes are binding. If the majority of all votes is positive, then the Podling SHALL send a summary of that vote to the Incubator's general list and formally request the Incubator PMC approve such a release."
>
> That's still the wording today.
>
> I've never been challenged on this approach (having mentored many podlings). It was my approach with the most recent release I was a part of, just last week (Ripple). The additional reviews received from the IPMC were useful, spotting a couple of small items, and turned up the one required +1 (only two binding mentor votes).
>
> Whether this is an accurate recollection of what was discussed way back, or whether this is just a practice I (and others) have fallen into and not been challenged on I urge the IPMC to consider this approach (of course, it does rely on proper oversight from mentors and the IPMC, I'm comfortable with this approach because I never vote +1 without having done due diligence on the release - I trust others do the same).
>
>
> Ross
>
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Sunday, July 26, 2015 6:05 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 8:41 PM, Ross Gardler <Ro...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
Well this explains how it got this way, it was poorly worded from the start...
The first part is about incoming code (the SGA) and nothing has changed there.
The second part says " SHALL formally request the Incubator PMC approve such a release" It does not say [VOTE] and it was never, IMHO, intended to be a separate vote (unless there were insufficient IPMC votes).
Speaking personally I have always (and I know many other mentors have also, certainly all those that have co-mentored with me) treated a vote on the podling list as binding and a "request" in the form of a notification (giving time to object if appropriate) when three positive IPMC votes have been cast.
In 2006 it said "Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL hold a vote on the Podling's public -dev list. At least three +1 votes are required (see the Apache Voting Process page), and only the PPMC member votes are binding. If the majority of all votes is positive, then the Podling SHALL send a summary of that vote to the Incubator's general list and formally request the Incubator PMC approve such a release."
That's still the wording today.
I've never been challenged on this approach (having mentored many podlings). It was my approach with the most recent release I was a part of, just last week (Ripple). The additional reviews received from the IPMC were useful, spotting a couple of small items, and turned up the one required +1 (only two binding mentor votes).
Whether this is an accurate recollection of what was discussed way back, or whether this is just a practice I (and others) have fallen into and not been challenged on I urge the IPMC to consider this approach (of course, it does rely on proper oversight from mentors and the IPMC, I'm comfortable with this approach because I never vote +1 without having done due diligence on the release - I trust others do the same).
Ross
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Sunday, July 26, 2015 6:05 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 8:41 PM, Ross Gardler <Ro...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by David Nalley <da...@gnsa.us>.
On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler
<Ro...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
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:cos@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 <ju...@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, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Konstantin Boudnik <co...@apache.org>.
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 <ju...@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
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Branko Čibej <br...@apache.org>.
On 26.07.2015 10:56, jan i wrote:
> On 26 July 2015 at 10:40, Justin Mclean <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>>> About 40% of the last 100 threads on general@ is "vote release"... Cut
>> that
>>> away is a good start in reforming the Incubator…
>> IMO Which provides a valuable service in showing poddlings on how to make
>> good releases. Do we want to get rid of that?
>>
> No that is an important service, on the other hand I also agree that the
> mentors should be guiding/running the podlings not general@
>
> Maybe we can find some middle ground.
> - Mentors "run" the podlings, can accept releases etc.
> - Mentors decide when a podlng can graduate (maybe with some form of, needs
> to accepted by all mentors of the project)
> - Any release must be announced (not voted) on general@, so that people
> like you have a chance of controlling it just like today.
>
> I think this would make incubator a lot more efficient, reduce our inboxes,
> and give us spare time to concentrate on other things.
I like this proposal very much. One of the constant frustrations in the
podlings I'd mentored was the delay between release bits being ready and
the IPMC getting around to vote. It's now a lot better than it was a
couple years ago, when in some instances it took a month or more ...
Concretely: I think it's perfectly OK to review podling releases after
the fact. The incubation disclaimer tells users clearly enough that they
should be extra careful when using releases from incubating projects.
The other frustration is of course evident in the Ignite graduation
discussion.
The only downside of this proposal is that it assumes that every podling
has at least three active (!) mentors. That doesn't always happen; and
currently we expect the podling to chase down inactive mentors or find
new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
active role in finding mentors for podlings.
Other than that, big +1.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Jul 26, 2015 at 1:56 AM, jan i <ja...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Jul 26, 2015 at 3:57 PM, Daniel Gruno <hu...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by jan i <ja...@apache.org>.
On 26 July 2015 at 10:40, Justin Mclean <ju...@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.
rgds
jan i.
>
> Thanks,
> Justin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Justin Mclean <ju...@classsoftware.com>.
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?
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Daniel Gruno <hu...@apache.org>.
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 Nalley<ma...@gnsa.us>
> Sent: 7/26/2015 12:36 PM
> To: general@incubator.apache.org<ma...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Ross Gardler <Ro...@microsoft.com>.
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 Nalley<ma...@gnsa.us>
Sent: 7/26/2015 12:36 PM
To: general@incubator.apache.org<ma...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Posted by David Nalley <da...@gnsa.us>.
>
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Just catching up on this thread. Going back a bit.
>> #2 The #1 goal is achieved via mentorship. In fact mentorship is
>> not even required as the case of Zest (and hopeful Yetus soon) demonstrated.
Not to pick on Zest but a casual glance at the current source release shows it contains a couple of jars and the Apache LICENSE is incomplete. I know nothing about Zest and these are probably (easily fixed) minor issues, but it does show that having someone outside your project reviewing releases can be useful.
If we as some people seem to be suggesting just announce podling releases on this list and not have an IPMC vote it seems to me we would be more likely to have releases with issues in them. Some of these would be minor and probably not matter but it does increase the risk. And if an issue is found what do we do about the previous releases? It seems( that checking often and early gives better results.
Automated tools can certainly find some issues but they IMO are never going to find every issue. How can an automated tool easily know that cat image is under copyright? Or that the original license header has been replaced with an Apache one on a file? Tools like this do exists but are probably prohibitive cost wise and time wise to implement across Apache.
I certainly think having clearer policy documentation would help and like Bertrands release checklist idea, but even having clear documentation (e.g. [1]) doesn’t seem to solve all issues. I can only assume that it comes down to we’re a bunch of volunteers and our time and focus is sometimes a little scattered so stuff sometimes gets missed.
Thanks,
Justin
1.http://www.apache.org/dev/licensing-howto.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org