incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <>
Subject Re: [DISCUSS] Expressing priorities about release reviews
Date Sat, 12 Jan 2013 22:59:54 GMT
The way I look at release reviews is that releases are the things that  
expose the Apache Foundation to the greatest legal risk, so it's  
critical that podlings learn to get them right. If they (podlings)  
don't get releases right in the incubator, what chance is there that  
they will succeed as a PMC?

Technical review can only be done by folks who are knowledgeable about  
the code base. These are the committers on the project. Process review  
can be done by mentors. Ideally, license and notice reviews should be  
done first by mentors. But I don't expect that mentors will  
necessarily know as much as people in IPMC (and other volunteer  
release reviewers) about the legal requirements for release.

 From my perspective, even though it is at times painful, the release  
process works well. Everyone in the incubator contributes what they  
can to make sure that podlings learn how to release, and how important  
it is to release clean code. Even if the code doesn't work, the  
process does.


On Jan 12, 2013, at 11:29 AM, Joe Schaefer wrote:

> Yes you make a good point- that any effort
> towards review is welcome and appreciated.
> It's just that having an exclusive focus
> on the things we can actually review here,
> namely adherence to License and Notice policy,
> can leave people with the mistaken impression
> that that's all that a PMC should concern itself
> with.  All of that daily effort that goes into
> validating commits on a project really should
> garner more appreciation from the PMC, if we
> could just find a way to be more trusting about
> who we let issue binding votes on behalf of
> the org.
> Really is it so bad to say to a project with
> a bug in their license and notice info: fix
> this in trunk and show me the revision and
> I'll go ahead and approve your release as-is.
> Running through iterations of this is very
> labor-intensive for the project, and anything
> we can do to cut down on the pain involved
> in cutting incubator releases is IMO worthwhile.
>> ________________________________
>> From: Sergio Fernández <>
>> To:
>> Cc: Joe Schaefer <>
>> Sent: Saturday, January 12, 2013 2:22 PM
>> Subject: Re: [DISCUSS] Expressing priorities about release reviews
>> Joe,
>> personally I appreciate such policies checking from the IPMC  
>> members. The technical quality of a release is responsibility of  
>> the project itself, which could be hard to be evaluated by people  
>> working on other topics. Therefore, all additional checkpoints are  
>> useful and grateful.
>> Cheers,
>> On 12/01/13 18:07, Joe Schaefer wrote:
>>> One of my long time pet peeves with how we
>>> PMC members participate in vetting releases
>>> is our penchant for focusing too much on the
>>> policies surrounding license and notice info.
>>> I really think our exclusive focus on things
>>> that really don't pose any organizational risk
>>> to either the org nor the project participants
>>> serves us well in our other, often unexpressed
>>> but far more relevant, goals about encouraging
>>> committers to participate in active review of
>>> their project's commit activity.
>>> Just think about this for a second, what's more
>>> likely for people to start suing us over, some
>>> bug in the NOTICE file or an undetected backdoor
>>> in one of our programs?  I am personally far more
>>> concerned about the current state of the actual
>>> review going on in our podlings than I am about
>>> NOTICE minutia.
>>> Maybe we should compile some list of which committers
>>> are actually subscribed to their project's commit lists?
>>> It's crude but it may be useful data to look at to
>>> a first order.
>> -- Sergio Fernández
>> Salzburg Research
>> +43 662 2288 318
>> Jakob-Haringer Strasse 5/II
>> A-5020 Salzburg (Austria)
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

Craig L Russell
Architect, Oracle
408 276-5638
P.S. A good JDO? O, Gasp!

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

View raw message