I'd like to try to break this down a bit. I'm ignoring, for this reply, the questions Joe raises about supervising things other than the legal metadata.
1. Why are podlings having so much trouble getting the legal metadata correct? Every single existing Apache release is a sample. The top problem area seems to be NOTICE and LICENSE, with notices on individual source files far behind. 2. I agree with some in this thread that problems in this area are not sufficient reason to block any _single_ release. Copyright comes into existence whether or not you paste a notice on it. Failing to respect a third-party notice requirement is rude, but, as someone pointed out, is not a giant legal exposure. I also have a suspicion that many podling _releases_ (i.e. the source) have, in fact, no third-party license exposure at all. While it might not deserve to block any one release, I agree with the point that we can't be graduating podlings who don't know how to maintain this metadata. If (and I'm not being rhetorical here) we treat these as 'fix it next time', we'd better be sure that there is a next time. 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? On Sat, Jan 12, 2013 at 5:59 PM, Craig L Russell <craig.russ...@oracle.com> wrote: > 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. > > Craig > > > > 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 <sergio.fernan...@salzburgresearch.at> >>> To: general@incubator.apache.org >>> Cc: Joe Schaefer <joe_schae...@yahoo.com> >>> 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) >>> http://www.salzburgresearch.at >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >>> > > Craig L Russell > Architect, Oracle > http://db.apache.org/jdo > 408 276-5638 mailto:craig.russ...@oracle.com > P.S. A good JDO? O, Gasp! > > > > --------------------------------------------------------------------- > 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
