Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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:j...@apache.org]
Sent: Tuesday, August 4, 2015 10:37
To: general@incubator.apache.org; orc...@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 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:bdelacre...@apache.org]
> Sent: Tuesday, August 4, 2015 05:57
> To: Incubator General
> 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 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Tue, Aug 4, 2015 at 9:15 AM, Joe Brockmeier 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 > j...@zonker.net > Twitter: @jzb > http://www.dissociatedpress.net/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Who are the village spinsters?
On Mon, Aug 3, 2015 at 1:21 PM, Branko Čibej 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
> wrote:
> >>
> >> " This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation.
> Which is grossly unfair at the board level, but unfortunately seems to be
> very true at IPMC level today."
> >>
> >> +1000
> >>
> >> -Original Message-----
> >> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of
> Roman Shaposhnik
> >> Sent: Monday, August 3, 2015 12:13 PM
> >> To: general@incubator.apache.org
> >> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite
> from the Apache Incubator)
> >>
> >> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
--
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)
Can you provide a pointer to a specific example of what you mean? On Mon, Aug 3, 2015 at 4:06 PM, Arvind Prabhakar wrote: > On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell > 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 > > wrote: > > > > > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament > > > 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-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@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)
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.mattm...@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
Reply-To: "general@incubator.apache.org"
Date: Tuesday, August 4, 2015 at 9:12 AM
To: "general@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<mailto:humbed...@apache.org>
>Sent: 8/4/2015 4:15 AM
>To: general@incubator.apache.org<mailto:general@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
>>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-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 4 August 2015 at 18:46, Dennis E. Hamilton 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:bdelacre...@apache.org]
> Sent: Tuesday, August 4, 2015 05:57
> To: Incubator General
> 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 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
+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:bdelacre...@apache.org]
Sent: Tuesday, August 4, 2015 05:57
To: Incubator General
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 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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<mailto:j...@zonker.net>
Sent: 8/4/2015 9:16 AM
To: general@incubator.apache.org<mailto:general@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 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
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015, at 03:13 PM, Roman Shaposhnik wrote: > On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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<mailto:humbed...@apache.org>
Sent: 8/4/2015 4:15 AM
To: general@incubator.apache.org<mailto:general@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 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Hi Daniel, On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 2015-08-04 13:01, Bertrand Delacretaz wrote: On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell 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 > wrote: > > > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament > > 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-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@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)
+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 wrote:
" This is that proverbial "political overhead" that a lot of folks are accusing ASF
of and cite as a reason of not going into the foundation. Which is grossly unfair at the board
level, but unfortunately seems to be very true at IPMC level today."
+1000
-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman
Shaposhnik
Sent: Monday, August 3, 2015 12:13 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
> 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 wrote: > On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament > 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@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)
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 wrote:
>>
>> " This is that proverbial "political overhead" that a lot of folks are
>> accusing ASF of and cite as a reason of not going into the foundation. Which
>> is grossly unfair at the board level, but unfortunately seems to be very
>> true at IPMC level today."
>>
>> +1000
>>
>> -Original Message-
>> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman
>> Shaposhnik
>> Sent: Monday, August 3, 2015 12:13 PM
>> To: general@incubator.apache.org
>> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
>> Apache Incubator)
>>
>> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 03.08.2015 18:36, Marvin Humphrey wrote: > It's not the central Incubator folks like our regular release > reviewers and report contributors who invent these extra criteria Sorry but this has to be said: I see folks on this list inventing policy (or rather, confusing opinion and policy) all the time. The Ignite graduation discussion was a good example of that, but by no means unique. It's this micromanagement self-preservation reflex (thanks, Roman!) that puts me squarely on the side of a smaller IPMC that would hopefully also be less of a peanut gallery. No offence meant and especially not to the people who do put in a stellar performance hereabouts. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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 wrote:
>
> " This is that proverbial "political overhead" that a lot of folks are
> accusing ASF of and cite as a reason of not going into the foundation. Which
> is grossly unfair at the board level, but unfortunately seems to be very true
> at IPMC level today."
>
> +1000
>
> -Original Message-
> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman
> Shaposhnik
> Sent: Monday, August 3, 2015 12:13 PM
> To: general@incubator.apache.org
> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
> Apache Incubator)
>
> On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
" This is that proverbial "political overhead" that a lot of folks are accusing
ASF of and cite as a reason of not going into the foundation. Which is grossly
unfair at the board level, but unfortunately seems to be very true at IPMC
level today."
+1000
-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman
Shaposhnik
Sent: Monday, August 3, 2015 12:13 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz wrote: > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
+1
-Original Message-
From: Marvin Humphrey [mailto:mar...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 8:48 AM, Arvind Prabhakar wrote: > On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz > wrote: > >> On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik >> 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz wrote: > On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik > 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, 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 j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 2015-08-03 09:37, Bertrand Delacretaz wrote: On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Aug 2, 2015 at 7:05 PM, Roman Shaposhnik 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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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
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
> 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:da...@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.gard...@microsoft.com> wrote:
> >> The proposed need to announce release votes on the IPMC list is how
> things were when the incubator was created. The need for IPMC to control
> the process is another case of the IPMC over-reaching itself and in so
> doing causing problems by creating a bottleneck in the process.
> >>
> >> It used to be that it was only required to *notify* the IPMC of a
> release vote underway. Thereby giving interested IPMC members the
> opportunity to review artifacts and processes during the normal release
> cycle. IPMC members were expected to cast their votes on the PPMC list
> where such things belong.
> >>
> >
> > I'd love to see links to that - my digging didn't find it. (see below)
> >
> >> I'm not sure where this idea that the vote actually occurs on the IPMC
> list came from but it's flat wrong in my opinion (someone may dig through
> the archives and find a good reason it was changed, but my feeling is that
> it changed g
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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
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:da...@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
> 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
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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:da...@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
wrote:
> The proposed need to announce release votes on the IPMC list is how things
> were when the incubator was created. The need for IPMC to control the process
> is another case of the IPMC over-reaching itself and in so doing causing
> problems by creating a bottleneck in the process.
>
> It used to be that it was only required to *notify* the IPMC of a release
> vote underway. Thereby giving interested IPMC members the opportunity to
> review artifacts and processes during the normal release cycle. IPMC members
> were expected to cast their votes on the PPMC list where such things belong.
>
I'd love to see links to that - my digging didn't find it. (see below)
> I'm not sure where this idea that the vote actually occurs on the IPMC list
> came from but it's flat wrong in my opinion (someone may dig through the
> archives and find a good reason it was changed, but my feeling is that it
> changed gradually through edits-on-edits-on-edits of the incubation policy).
>
> The fact is that the PPMC (with IPMC representation from the mentors) should
> be in charge of their releases, and pretty much everything else. The IPMC
> role is one of teaching the PPMC how manage itself. Mentors should do this
> through mentoring and the IPMC should ensure it is done through an
> appropriate level of oversight (not an inappropriate amount of control).
>
> Consider this... The board does not bring TLP release votes to board@, why on
> earth must the IPMC do so?
>
> I've half a mind to got back the wayback machine and pull the original
> incubator polices and propose them as the "new" policies (yes, some
> changes have been good, but it seems to me that many have not)
>
So I couldn't find anything in 2003, but 2004 has this page[1] which included
the text:
"Podlings in Incubation SHALL NOT perform any releases of software without the
explicit approval of the Incubator PMC. Such approval SHALL be given only after
the Incubator PMC has followed the process detailed in (Reference to Charter),
and SHALL NOT occur until all source has been legally transferred to the ASF."
and
"Therefore, should a Podling decide it wishes to perform a release, the Podling
SHALL formally request the Incubator PMC approve such a release. The request
SHALL have the endorsement of the Mentor."
So it seems that this has been with us for a long while.
[1]
https://web.archive.org/web/20041010183702/http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler wrote: > The proposed need to announce release votes on the IPMC list is how things > were when the incubator was created. The need for IPMC to control the process > is another case of the IPMC over-reaching itself and in so doing causing > problems by creating a bottleneck in the process. > > It used to be that it was only required to *notify* the IPMC of a release > vote underway. Thereby giving interested IPMC members the opportunity to > review artifacts and processes during the normal release cycle. IPMC members > were expected to cast their votes on the PPMC list where such things belong. > I'd love to see links to that - my digging didn't find it. (see below) > I'm not sure where this idea that the vote actually occurs on the IPMC list > came from but it's flat wrong in my opinion (someone may dig through the > archives and find a good reason it was changed, but my feeling is that it > changed gradually through edits-on-edits-on-edits of the incubation policy). > > The fact is that the PPMC (with IPMC representation from the mentors) should > be in charge of their releases, and pretty much everything else. The IPMC > role is one of teaching the PPMC how manage itself. Mentors should do this > through mentoring and the IPMC should ensure it is done through an > appropriate level of oversight (not an inappropriate amount of control). > > Consider this... The board does not bring TLP release votes to board@, why on > earth must the IPMC do so? > > I've half a mind to got back the wayback machine and pull the original > incubator polices and propose them as the "new" policies (yes, some changes > have been good, but it seems to me that many have not) > So I couldn't find anything in 2003, but 2004 has this page[1] which included the text: "Podlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator PMC. Such approval SHALL be given only after the Incubator PMC has followed the process detailed in (Reference to Charter), and SHALL NOT occur until all source has been legally transferred to the ASF." and "Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL formally request the Incubator PMC approve such a release. The request SHALL have the endorsement of the Mentor." So it seems that this has been with us for a long while. [1] https://web.archive.org/web/20041010183702/http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
The proposed need to announce release votes on the IPMC list is how things were
when the incubator was created. The need for IPMC to control the process is
another case of the IPMC over-reaching itself and in so doing causing problems
by creating a bottleneck in the process.
It used to be that it was only required to *notify* the IPMC of a release vote
underway. Thereby giving interested IPMC members the opportunity to review
artifacts and processes during the normal release cycle. IPMC members were
expected to cast their votes on the PPMC list where such things belong.
I'm not sure where this idea that the vote actually occurs on the IPMC list
came from but it's flat wrong in my opinion (someone may dig through the
archives and find a good reason it was changed, but my feeling is that it
changed gradually through edits-on-edits-on-edits of the incubation policy).
The fact is that the PPMC (with IPMC representation from the mentors) should be
in charge of their releases, and pretty much everything else. The IPMC role is
one of teaching the PPMC how manage itself. Mentors should do this through
mentoring and the IPMC should ensure it is done through an appropriate level of
oversight (not an inappropriate amount of control).
Consider this... The board does not bring TLP release votes to board@, why on
earth must the IPMC do so?
I've half a mind to got back the wayback machine and pull the original
incubator polices and propose them as the "new" policies (yes, some changes
have been good, but it seems to me that many have not)
Ross
-Original Message-
From: Konstantin Boudnik [mailto:c...@apache.org]
Sent: Sunday, July 26, 2015 5:15 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote:
> On 26.07.2015 10:56, jan i wrote:
> > On 26 July 2015 at 10:40, Justin Mclean 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
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 wrote: > > > >> Hi, > >> > >>> About 40% of the last 100 threads on general@ is "vote release"... Cut > >> that > >>> away is a good start in reforming the Incubator… > >> IMO Which provides a valuable service in showing poddlings on how to make > >> good releases. Do we want to get rid of that? > >> > > No that is an important service, on the other hand I also agree that the > > mentors should be guiding/running the podlings not general@ > > > > Maybe we can find some middle ground. > > - Mentors "run" the podlings, can accept releases etc. > > - Mentors decide when a podlng can graduate (maybe with some form of, needs > > to accepted by all mentors of the project) > > - Any release must be announced (not voted) on general@, so that people > > like you have a chance of controlling it just like today. > > > > I think this would make incubator a lot more efficient, reduce our inboxes, > > and give us spare time to concentrate on other things. > > I like this proposal very much. One of the constant frustrations in the > podlings I'd mentored was the delay between release bits being ready and > the IPMC getting around to vote. It's now a lot better than it was a > couple years ago, when in some instances it took a month or more ... > > Concretely: I think it's perfectly OK to review podling releases after > the fact. The incubation disclaimer tells users clearly enough that they > should be extra careful when using releases from incubating projects. > > The other frustration is of course evident in the Ignite graduation > discussion. > > The only downside of this proposal is that it assumes that every podling > has at least three active (!) mentors. That doesn't always happen; and > currently we expect the podling to chase down inactive mentors or find > new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more > active role in finding mentors for podlings. > > Other than that, big +1. I like the idea of the post factum release reviews. It doesn't mean that IPMC at large aren't welcome to jump in and help with the podling release voting. Perhaps a sane and courteous thing would be to Cc: general@ on the podling [VOTE] thread? But +1 even as it stands right now. One of the moot points that has came up a few times recently about the diversity clause in the graduation guidelines. Namely: "A major criterion for graduation is to have developed an open and diverse meritocratic community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones." The semantic of "diverse" isn't clear and is being interpreted in different ways. I'd like to propose to change the above paragraph to "A major criterion for graduation is to have developed an open and meritocratic community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones." to avoid possible confusing interpretations in the future. Regards, Cos signature.asc Description: Digital signature
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 2015-07-27 01:20, Roman Shaposhnik wrote: I'd like to raise a somewhat orthogonal point. Mainly the fact that our obsession with doing good work with podlings could, very well, be obscuring a much more important issues. And given how limited our resources of eyeballs looking at releases are -- we need to be practical. Now, while I couldn't agree more that IP hygiene of releases is one of the corner stones of what makes ASF what it is, I have to be realistic in accepting the fact that once podling is out of the incubation and becomes a TLP the level of external scrutiny drops by 90% and all bets are off. Some TLPs do great releases. Some do really poor ones. Sometimes ppl notify the board. Once again, I can't be happier that there are folks like Justin who spend an enormous amount of their personal time helping to vet releases of podlings. I only ask: should his (and guys like him) time be better applied to helping foundation make sure that our TLPs are doing what they are supposed to do as well? I too am very delighted that we have volunteers who are both willing and able to help us through these somewhat dry and dusty areas of releasing software. I believe our time is better spent if we educate new podlings on proper release and IP procedures, so as to prevent these things from happening later on when they are released into the apache wilds with the 273 other projects, and as such, I think it's better to have these checks (and the people doing the checks) in the incubator. Having said that, I do realize this puts a lot of pressure on very few people, and the asynchronicity of going back and forth between podling and incubator is not the optimal way. But I believe this is something the incubator needs to teach podlings. What if, for example, we were to come up with a more automated and educational system for this, so as to get it faster through the human control? We already have Rat that does most of this, so couldn't we make a "super rat" that does a bit more, specifically designed to educate the incubating podlings, maybe a web interface where you just throw a tarball at it and it'll tell you what needs to be improved. Sure, it would have a significant cost in people hours at first, but if the Incubator is going to be around for another decade or more, it would definitely pay off in the end and make initial releases faster. I'd be happy to collaborate with others on this, if there is an interest in giving it a go. With regards, Daniel. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Jul 26, 2015 at 3:57 PM, Daniel Gruno wrote: > > > On 2015-07-26 10:56, jan i wrote: >> >> No that is an important service, on the other hand I also agree that the >> mentors should be guiding/running the podlings not general@ >> >> Maybe we can find some middle ground. >> - Mentors "run" the podlings, can accept releases etc. >> - Mentors decide when a podlng can graduate (maybe with some form of, >> needs >> to accepted by all mentors of the project) >> - Any release must be announced (not voted) on general@, so that people >> like you have a chance of controlling it just like today. >> >> I think this would make incubator a lot more efficient, reduce our >> inboxes, >> and give us spare time to concentrate on other things. >> >> rgds >> jan i. > > This is somewhat similar to the 2013 alternate release policy we have, > whereby the first release has to do the initial IPMC clearance vote, but > subsequent releases only need the mentors' approval. I believe our current > policy is sound and has proven itself effective, as you can see by the many > times a new podling's release has been caught by the "policy watch dogs" we > have in the IPMC that specialize in reviewing material that is to be > released. > > Optionally, if we aim to 'save space in our inboxes', we could generate a > new group of people on a specific ML designed for initial release > verification, and all _first releases_ would go through that list and have > things checked, while only sending a NOTICE to the general incubator list on > successfully released software. > > I do not, however, think we should just scrap the current rule of having the > outside judge the initial release, as it has been shown, time after time, > that it really does help to have this external review. I'd like to raise a somewhat orthogonal point. Mainly the fact that our obsession with doing good work with podlings could, very well, be obscuring a much more important issues. And given how limited our resources of eyeballs looking at releases are -- we need to be practical. Now, while I couldn't agree more that IP hygiene of releases is one of the corner stones of what makes ASF what it is, I have to be realistic in accepting the fact that once podling is out of the incubation and becomes a TLP the level of external scrutiny drops by 90% and all bets are off. Some TLPs do great releases. Some do really poor ones. Sometimes ppl notify the board. Once again, I can't be happier that there are folks like Justin who spend an enormous amount of their personal time helping to vet releases of podlings. I only ask: should his (and guys like him) time be better applied to helping foundation make sure that our TLPs are doing what they are supposed to do as well? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 2015-07-26 10:56, jan i wrote: No that is an important service, on the other hand I also agree that the mentors should be guiding/running the podlings not general@ Maybe we can find some middle ground. - Mentors "run" the podlings, can accept releases etc. - Mentors decide when a podlng can graduate (maybe with some form of, needs to accepted by all mentors of the project) - Any release must be announced (not voted) on general@, so that people like you have a chance of controlling it just like today. I think this would make incubator a lot more efficient, reduce our inboxes, and give us spare time to concentrate on other things. rgds jan i. This is somewhat similar to the 2013 alternate release policy we have, whereby the first release has to do the initial IPMC clearance vote, but subsequent releases only need the mentors' approval. I believe our current policy is sound and has proven itself effective, as you can see by the many times a new podling's release has been caught by the "policy watch dogs" we have in the IPMC that specialize in reviewing material that is to be released. Optionally, if we aim to 'save space in our inboxes', we could generate a new group of people on a specific ML designed for initial release verification, and all _first releases_ would go through that list and have things checked, while only sending a NOTICE to the general incubator list on successfully released software. I do not, however, think we should just scrap the current rule of having the outside judge the initial release, as it has been shown, time after time, that it really does help to have this external review. With regards, Daniel. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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 wrote: >> >> Empower the Mentors to run the podlings, teach the newcomers and bring it >> to TLP. >> > > As a mentor of podlings, I dislike the above idea. > > Mentors get busy, they miss things, sometimes big things. Sometimes > things that are obvious to an outsider are missed by mentors who don't > catch it. I've certainly been guilty of missing things, and having an > 'outside IPMC member' call attention to that has caused me to go find > not just that problem, but other problems with a podling. > > Even on smaller issues, Justin and Sebb run circles around me in > validating that releases comply with policy. I've voted affirmatively > on releases that Justin or Sebb has found issues; occasionally glaring > issues. I do not think that just because I am a mentor on $project and > they aren't invalidates concerns they may raise. I may have additional > insight, and be able to explain things. > > Similarly, a vote was brought to the IPMC as to whether or not to > recommend graduation. We asked people to inspect the podling and vote, > and for some reason seem displeased when everyone doesn't unanimously > agree with the mentors. I am not sure whether to interpret that as > 'non-mentor IPMC votes are discouraged', or whether 'dissenting > opinions are discouraged'. But telling the body responsible (the IPMC) > to leave podlings in its charge alone, particularly when prompted by a > vote called by the podling itself hardly seems appropriate. > > --David > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Jul 26, 2015 at 9:50 AM, toki wrote: > > > On 07/26/2015 04:35 PM, jan i wrote: > >> unless we don't trust the mentors > > It isn't a case of not trusting the mentors, but rather, the ease with > which something can be accidentally overlooked. > > Rephrased. The mentor is too close to the project, to see all of the > errors in the project. An how is this different from TLP's PMC? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Jul 26, 2015 at 1:56 AM, 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. I really like this idea. Huge +1. How can we, please, make it a reality? Do we need to draft a new set of by laws/policies for the IPMC or is there a more gradual approach to putting this into practice? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 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<mailto:da...@gnsa.us>
Sent: 7/26/2015 12:36 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
Empower the Mentors to run the podlings, teach the newcomers and bring it
to TLP.
As a mentor of podlings, I dislike the above idea.
Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.
Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.
Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.
--David
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
Since I am relatively new to the Incubator (given that it turns 13 in just 2½ month), I will ask a question that may have been answered in the earlier years: Have we given any thought to some sort of mentor rotation policy? One could argue that what we especially lack right now is the 'outsider' view on podlings before it is 'too late', so perhaps changing (or at least adding some new) mentors along the way, not just by choice, but by design/policy, we could perhaps, just perhaps, catch some potential cases of myopia or "in the loop" issues that seems to, arguably, be the cause of some of the concerns raised lately. I realize that this, with the ASF being an all volunteer org, is not something you simply implement in a fortnight, but I think it's worth discussing. With regards, Daniel. On 2015-07-26 22:33, Ted Dunning wrote: I think my own experience as a mentor over recent years is useful here. I thought I understood what was necessary for apache releases when, in fact, I understood release requirements for releases like the ones I had previously seen. The wider by shepherds and by the general votes was a pain because of the added delay but it substantially increased the quality of the releases and improved the processes the group had. With more perspective now, I find that individual mentors often have somewhat specialized expertise and my experience was absolutely not unique. Marvin and Ross also make good and important points orthogonal to this. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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<mailto:da...@gnsa.us>
Sent: 7/26/2015 12:36 PM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
>
> Empower the Mentors to run the podlings, teach the newcomers and bring it
> to TLP.
>
As a mentor of podlings, I dislike the above idea.
Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.
Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.
Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.
--David
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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 wrote: >> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman 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 wrote: >> >> It's now a lot better than it was a >> couple years ago, when in some instances it took a month or more ... > > Yes, we have for the most part solved the problem of RCs twisting in the wind. > Both proposals in this thread will bring that problem back. > > Mentor attrition is a fundamental law of the Incubator: because Mentors are > not core contributors, they fall away at increased rate. It is not possible > to change that fact, only to compensate for it. > > The wider IPMC has a certain limited capacity for picking up the slack on > release votes. Since the end of 2013, we have been using that precious > capacity wisely. > > These proposals squander that capacity and put it all back on the Mentors. > Some of those Mentors will be unavailable when they are needed, compounding > the difficulties faced by smaller and more troubled podlings. > >> Concretely: I think it's perfectly OK to review podling releases after >> the fact. The incubation disclaimer tells users clearly enough that they >> should be extra careful when using releases from incubating projects. > > We routinely see problematic release candidates on general@incubator. It > would seem that the expertise and temperament for exacting release QC is not > evenly distributed among the Mentor corps -- just like other valuable skills > and talents. > > Since 2013, the wider IPMC in collaboration with Mentors has been working > well at cleaning up problematic releases in an expedited manner -- and once a > podling is producing clean releases regularly, it is probably nearing > graduation and will not be affected by the extra 3 days for long. I don't see > any urgency to change this dynamic. > >> The other frustration is of course evident in the Ignite graduation >> discussion. > > The outcome of the Ignite graduation discussion was never in doubt. The wider > IPMC was never going to vote down graduation when there were multiple > attentive Ignite Mentors united in favor -- it was only a matter of time > before people came around. > > I think the discussion was more voluminous than it needed to be, but I > attribute that to individual participants sending too many emails in one day. > 1-2 per day on a given thread is a good rate. > > In the meantime, interested podling observers got to witness a decent debate > on project independence and off-list dev discussion -- which is generally one > of the hardest aspects of Apache-style open development to master. > >> The only downside of this proposal is that it assumes that every podling >> has at least three active (!) mentors. That doesn't always happen; and >> currently we expect the podling to chase down inactive mentors or find >> new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more >> active role in finding mentors for podlings. > > Recruiting Mentors for podlings at any stage other than entry has always been > difficult. It would be deeply unfair to small podlings to establish a policy > which denies this reality. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
> > Empower the Mentors to run the podlings, teach the newcomers and bring it > to TLP. > As a mentor of podlings, I dislike the above idea. Mentors get busy, they miss things, sometimes big things. Sometimes things that are obvious to an outsider are missed by mentors who don't catch it. I've certainly been guilty of missing things, and having an 'outside IPMC member' call attention to that has caused me to go find not just that problem, but other problems with a podling. Even on smaller issues, Justin and Sebb run circles around me in validating that releases comply with policy. I've voted affirmatively on releases that Justin or Sebb has found issues; occasionally glaring issues. I do not think that just because I am a mentor on $project and they aren't invalidates concerns they may raise. I may have additional insight, and be able to explain things. Similarly, a vote was brought to the IPMC as to whether or not to recommend graduation. We asked people to inspect the podling and vote, and for some reason seem displeased when everyone doesn't unanimously agree with the mentors. I am not sure whether to interpret that as 'non-mentor IPMC votes are discouraged', or whether 'dissenting opinions are discouraged'. But telling the body responsible (the IPMC) to leave podlings in its charge alone, particularly when prompted by a vote called by the podling itself hardly seems appropriate. --David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
> On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman 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 wrote: > It's now a lot better than it was a > couple years ago, when in some instances it took a month or more ... Yes, we have for the most part solved the problem of RCs twisting in the wind. Both proposals in this thread will bring that problem back. Mentor attrition is a fundamental law of the Incubator: because Mentors are not core contributors, they fall away at increased rate. It is not possible to change that fact, only to compensate for it. The wider IPMC has a certain limited capacity for picking up the slack on release votes. Since the end of 2013, we have been using that precious capacity wisely. These proposals squander that capacity and put it all back on the Mentors. Some of those Mentors will be unavailable when they are needed, compounding the difficulties faced by smaller and more troubled podlings. > Concretely: I think it's perfectly OK to review podling releases after > the fact. The incubation disclaimer tells users clearly enough that they > should be extra careful when using releases from incubating projects. We routinely see problematic release candidates on general@incubator. It would seem that the expertise and temperament for exacting release QC is not evenly distributed among the Mentor corps -- just like other valuable skills and talents. Since 2013, the wider IPMC in collaboration with Mentors has been working well at cleaning up problematic releases in an expedited manner -- and once a podling is producing clean releases regularly, it is probably nearing graduation and will not be affected by the extra 3 days for long. I don't see any urgency to change this dynamic. > The other frustration is of course evident in the Ignite graduation > discussion. The outcome of the Ignite graduation discussion was never in doubt. The wider IPMC was never going to vote down graduation when there were multiple attentive Ignite Mentors united in favor -- it was only a matter of time before people came around. I think the discussion was more voluminous than it needed to be, but I attribute that to individual participants sending too many emails in one day. 1-2 per day on a given thread is a good rate. In the meantime, interested podling observers got to witness a decent debate on project independence and off-list dev discussion -- which is generally one of the hardest aspects of Apache-style open development to master. > The only downside of this proposal is that it assumes that every podling > has at least three active (!) mentors. That doesn't always happen; and > currently we expect the podling to chase down inactive mentors or find > new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more > active role in finding mentors for podlings. Recruiting Mentors for podlings at any stage other than entry has always been difficult. It would be deeply unfair to small podlings to establish a policy which denies this reality. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 07/26/2015 04:35 PM, jan i wrote: > unless we don't trust the mentors It isn't a case of not trusting the mentors, but rather, the ease with which something can be accidentally overlooked. Rephrased. The mentor is too close to the project, to see all of the errors in the project. jonathon signature.asc Description: OpenPGP digital signature
RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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<mailto:nic...@hedhman.org>
Sent: 7/26/2015 8:08 AM
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the
Apache Incubator)
On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej 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)
On Sunday, July 26, 2015, Don Bosco Durai 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" > > wrote: > > >On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej > wrote: > > > >> The only downside of this proposal is that it assumes that every podling > >> has at least three active (!) mentors. > > > >No, I don't necessarily mean that you need 3 mentors either. One active > >mentor would be fine with me. Empower the podling to stand on its own > >feet. > >The Incubation disclaimers are plenty warning, otherwise it would be full > >releases. > > > >Take a poll among podlings and ask "Do you want to be more autonomous from > >the IPMC?" and see what they say... > > > >Cheers > >-- > >Niclas Hedhman, Software Developer > >http://zest.apache.org - New Energy for Java > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > -- Sent from My iPad, sorry for any misspellings.
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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" wrote: >On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej wrote: > >> The only downside of this proposal is that it assumes that every podling >> has at least three active (!) mentors. > >No, I don't necessarily mean that you need 3 mentors either. One active >mentor would be fine with me. Empower the podling to stand on its own >feet. >The Incubation disclaimers are plenty warning, otherwise it would be full >releases. > >Take a poll among podlings and ask "Do you want to be more autonomous from >the IPMC?" and see what they say... > >Cheers >-- >Niclas Hedhman, Software Developer >http://zest.apache.org - New Energy for Java - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej 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)
On 26.07.2015 10:56, jan i wrote: > On 26 July 2015 at 10:40, Justin Mclean wrote: > >> Hi, >> >>> About 40% of the last 100 threads on general@ is "vote release"... Cut >> that >>> away is a good start in reforming the Incubator… >> IMO Which provides a valuable service in showing poddlings on how to make >> good releases. Do we want to get rid of that? >> > No that is an important service, on the other hand I also agree that the > mentors should be guiding/running the podlings not general@ > > Maybe we can find some middle ground. > - Mentors "run" the podlings, can accept releases etc. > - Mentors decide when a podlng can graduate (maybe with some form of, needs > to accepted by all mentors of the project) > - Any release must be announced (not voted) on general@, so that people > like you have a chance of controlling it just like today. > > I think this would make incubator a lot more efficient, reduce our inboxes, > and give us spare time to concentrate on other things. I like this proposal very much. One of the constant frustrations in the podlings I'd mentored was the delay between release bits being ready and the IPMC getting around to vote. It's now a lot better than it was a couple years ago, when in some instances it took a month or more ... Concretely: I think it's perfectly OK to review podling releases after the fact. The incubation disclaimer tells users clearly enough that they should be extra careful when using releases from incubating projects. The other frustration is of course evident in the Ignite graduation discussion. The only downside of this proposal is that it assumes that every podling has at least three active (!) mentors. That doesn't always happen; and currently we expect the podling to chase down inactive mentors or find new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more active role in finding mentors for podlings. Other than that, big +1. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
On 26 July 2015 at 10:40, Justin Mclean 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-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
