----- Original Message ----- > From: Dave Fisher <dave2w...@comcast.net> > To: general@incubator.apache.org > Cc: > Sent: Thursday, July 26, 2012 6:33 PM > Subject: Re: Incubator release task force > > > On Jul 26, 2012, at 3:07 PM, Joe Schaefer wrote: > >>> ________________________________ >>> From: Upayavira <u...@odoko.co.uk> >>> To: general@incubator.apache.org >>> 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.
I'm sure I speak for Marvin when I say I would love to participate on a task force dedicated to producing such documentation, but I am also weary about writing about a whole bunch of hypotheticals that nobody (other than Roy) has a really good handle on anyway. Yes, it's far easier for podlings to repeat what some existing project has done than to recognize their situation as belonging to an abstract category we have addressed somehow here. I worry about arming the people who fuss about such stuff as if it were critical to address everything in *this* release instead of simply accepting a promise to fix certain things in the next. > > 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. > > Regards, > Dave > >> > > > >> >> --------------------------------------------------------------------- >> 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
