----- 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]
