incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Basing Apache releases on releases from incubating projects
Date Wed, 01 Dec 2010 18:42:47 GMT
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)" <chris.a.mattmann@jpl.nasa.gov>
>> To: "general@incubator.apache.org" <general@incubator.apache.org>
>> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message