incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Basing Apache releases on releases from incubating projects
Date Wed, 01 Dec 2010 18:24:04 GMT
----- 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


Mime
View raw message