> This is the one point I am hesitant about. I think it would be > reasonable to ask us for a history of more than a single release
True, but I'd characterize this differently. A single release is not necessarily a single data point. The Kafka community endured an arduous series of RCs that exposed its members to a wide range of Apache processes, conventions, and individual members. There was a lot of experience transferred in that one release. Further, observation of that episode (broadcast broadly on general@incubator) should yield sufficient data for any interested observer to extrapolate the podling's chances as a TLP. That said, a point release would round out the incubation and spread RM experience among other members of the project. I'd also recommend option (2) for that reason, but hope graduation would soon follow. > (and > I'm not sure we got the mirror situation 100% right yet). We sure we > got this one? Huh... is this why the Clutch status page isn't all green? http://incubator.apache.org/clutch.html -C On Wed, Jun 6, 2012 at 12:51 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > This is a fair point. I am not sure of the best practices on the number of > releases to do before graduation. The Incubator docs imply a fairly low > bar: > "Projects need to cut releases. Apache projects need to understand how to > cut Apache releases. Therefore it is an important step during your stay in > the incubator to demonstrate the ability to create an Apache Release. Podlings > do not need to actually *publish* a release to demonstrate that they > understand how to accomplish such a feat. However, creating a release that > is approved by the incubator project management > committee<http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Incubator+Project+Management+Committee+%28PMC%29> > is usually the simplest way to do this." > (http://incubator.apache.org/guides/graduation.html#releases) > > They refer to "a release" not "releases", and mention that they don't > particularly care if you publish it or not. We might want to set a higher > bar for ourselves, though. > > We had planned on having 0.8 be the next release, and that is still a few > months out I suspect. However we did take a number of minor features and > fixes post 0.7 that are only on trunk it would probably be possible to do a > 0.7.1 without too much drama and that would make that work available to > people in a more easily consumable form . On the other hand it would be > nice to just be heads down and focus on 0.8 too. So if people agree with > Chris's feedback there are three options: > > 1. Pursue graduation now > 2. Do a 0.7.1 release, pursue graduation when that is completed > 3. Wait until 0.8 is out, pursue graduation after that > > Anyone have a strong preference for one of these options? > > -Jay > > On Tue, Jun 5, 2012 at 7:17 PM, Chris Burroughs > <chris.burrou...@gmail.com>wrote: > >> On 2012-05-23 23:32, Alan D. Cabrera wrote: >> >> We struggled a bit with licensing and packaging issues but we got those >> >> issues resolved and did a release and this should be pretty easy going >> >> forward. >> >> This is the one point I am hesitant about. I think it would be >> reasonable to ask us for a history of more than a single release (and >> I'm not sure we got the mirror situation 100% right yet). We sure we >> got this one? >> >> For the more important parts, It's exciting to see the community grow >> (particular the diversity part, that's a great accomplishment and I know >> takes significant commitment). On that note I would be interested in >> hearing from other committers about graduation. >>
