Hey Joe, I agree with pretty much everything you said below. One good thing (and correct me if I'm wrong) but is that I interpret what you are saying here:
> This is not an academic question. Ask Dims how things worked for > Geronimo when they had such a dependency. Basically the expectation > is that the dependent project will check the code into their own tree > and finish whatever vetting needs to take place. It then becomes a part > of *their* release process, not treated as an external dependency (how > they bundle that software doesn't really matter). to mean that it's the decision of the project who is including the dependency's source code in their own source code (and that is a mechanism to achieve what I'm proposing). If that's what you are saying then I agree. Even if that's not, I think I more or less am fine with what you're saying and sorry for causing everyone the email spam! I'm putting my head back down to work for the rest of the day! :) Cheers, Chris On Dec 1, 2010, at 10:24 AM, Joe Schaefer wrote: > ----- Original Message ---- > >> From: "Mattmann, Chris A (388J)" <[email protected]> >> To: "[email protected]" <[email protected]> >> Sent: Wed, December 1, 2010 1:14:03 PM >> Subject: Re: Basing Apache releases on releases from incubating projects >> >> Hi Joe, >> >>>> than going to some other OSS provider and then coming here >>>> later. >>> >>> You're confused about the whole point of releases at Apache. >>> They aren't necessarily meant to offer any promises about >>> stability or suitability for a given purpose, they are simply >>> meant as a means of getting the code out the door in a formal >>> and responsible way (given that we *are* a corporation). Too >>> many projects fail to release alpha and beta quality >>> code, and that's not the org's, nor the Incubator's, fault. >>> >> >> Not sure I'm confused, just poking actually, but near the end of my poking. >> >> Question: if podlings fail to make a release, but still >> have code checked into our Apache SVN and say they've went >> through a code grant, they've done ICLAs for all the committers, >> and everything looks OK, but the community dies, then how can >> folks depend on that code if it's got some nice features they >> want to include? What's the barrier there? The code is in our SVN, >> it's licensed using our license, there's been some diligence to >> check it (but maybe not full, etc.), etc. > > This is not an academic question. Ask Dims how things worked for > Geronimo when they had such a dependency. Basically the expectation > is that the dependent project will check the code into their own tree > and finish whatever vetting needs to take place. It then becomes a part > of *their* release process, not treated as an external dependency (how > they bundle that software doesn't really matter). > >> Anyhoo a lot of this is moot if the person is just willing to work >> the process to try and help make the podling release. But that doesn't >> work in all cases. There are some communities I can push on/help/etc., >> as much as I can, and they still won't make the release, that's just >> the nature of the beast. > > IMO part of the problem is that we still treat the IPMC as a bunch of > super-special people with very-special responsibilities. Podlings tend > to look at releases as a PITA because it's a hoop-jumping exercise performed > at the behest of the IPMC, instead of something innately in their own > best interests. > > My solution is to identify, as early as possible, people within the projects > who both know the codebase and will perform competent review of commits and > releases. Those people belong on the IPMC, and if we really took the vetting > process seriously that's how things would work. > > Successful release managers are almost always natural candidates for IPMC > membership. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
