incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Incubator release task force
Date Thu, 26 Jul 2012 22:33:35 GMT

On Jul 26, 2012, at 3:07 PM, Joe Schaefer wrote:

>> ________________________________
>> From: Upayavira <>
>> To: 
>> Sent: Thursday, July 26, 2012 5:37 PM
>> Subject: Re: Incubator release task force
>> Marvin,
>> While I (think I) can understand your concern (that it should be the
>> mentors who are reviewing releases, not yet another group), I'd suggest
>> that Jukka's approach might be a way to get there.
> Not for me- it is the podling's PPMC that needs to vet them properly,
> and we need to ensure that people who do a good job at that are suitably
> empowered to cast binding votes on release candidates.  I can see why
> podlings will be challenged for IPMC votes the first time thru, but
> by the third release they should have enough IPMC participation in their
> podling that the thought of coming to general@ and begging for votes
> won't ever occur to them.
> The reasons why we don't do this have nothing to do with the release process
> or its documentation- it's just social norms colliding from different
> areas of the ASF.
>> The incubator release process is, at the moment, pretty fraught, and I
>> suspect there are only a handful of people who really get it. I would
> It sucks for the same old tired rationale behind excluding competent
> peer reviewers from the halls of power here.  Some of us think this
> is a core failing of the IPMC, others disagree.  If Jukka can satisfy
> the anti-progressives and bring in more people willing to do a competent
> job of reviewing candidates simply because these people are trying to
> review other-podling candidates, more power to him.  Again I will say
> that this is slightly missing the point about *competent* review versus
> a casual glance at licensing issues that someone unskilled in a codebase
> might AT-BEST provide.
>> posit that one outcome of Jukka's suggestion is a simplified release
>> process, which is likely to be understandable to a larger number of
>> mentors, meaning you address your core issue.
> The release process *is* simple but laborious- it's supposed to be that way.
> But if you've done one successful release iterating on those learnings
> is considerably easier than trying to do it from scratch with just our
> bloated process docs.

I think that the problem is navigating the documentation. Most IP and packaging questions
have specific circumstances. It should be possible to look for answers using this data.

As a mentor I would really like to be able to point to either a decision tree or matrix for
how to include, produce and consume binary artifacts, build dependencies, and source license
categories in svn, source releases, and unofficial binary artifacts.

Podlings can then lookup the answer according to the circumstance. The answer can reference
the bloated docs for the reasoning.

To avoid creating meta-bloat these trees and matrices would need to be kept to an absolute
minimum with broad categories.



> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message