Yes, *AND* ensuring legal dots are put on the i's and j's. This is done through checking the release and ensuring that it is in adherence to our policies which you and others have crafted. *All* podlings have to ensure they have the correct licensing headers, notices and other bits in place before they can graduate.
AFAIK releases done by podlings are legally more sound than established projects at Apache. Do you consider that a bad thing? What strikes me is that because the SVN project has many old boys network guys on board, somehow the policy to what all podlings are subjected to is no longer valid? Have an incubator release? (nah, we are better at releasing because we have long standing members) Migrate all subscribers to the mailinglists from one legal organization to another? (afaik this is legally forbidden) Hosting non-Apache released artifacts at Apache hardware? These things are/were off-limits to podlings that were established and functioning outside Apache just fine. Wicket's incubation was rather painful due to not being able to transfer subscribers and hosting old releases and websites at Apache. I'm fine with short circuiting all the red tape associated with the incubator, but be warned: this will open up doors for other podlings as well. When the next established open source project comes along they expect (rightfully so) the same treatment as Subversion. Martijn On Mon, Nov 9, 2009 at 2:25 AM, Greg Stein <gst...@gmail.com> wrote: > The Apache Incubator is about EDUCATION. It is about TEACHING podlings > how to work here at Apache. > > It is not about making podlings thoughtlessly follow checklists. > > It is about TEACHING them what are the important aspects of > development at Apache. About SHOWING them each of the items to be > aware of. > > It is not about blind adherence to rules and procedure without regard > to the podling's experience. > > It is about LEARNING who the podling is, what they do, what they have > done, and what they are capable of, and producing a TEACHING > experience for that podling so that they can be an effective and > proper project here at the ASF. > > --- > > I was thinking, "hey. no problem. we can go a bit out of our way and > produce a release tuned for the Incubator needs" and made a > suggestion. That didn't satisfy some people, so further requirements > were thrown in. "hmm", I thought, "well... that shouldn't be too much > more of a burden". > > And then I received Craig's email below, and it brought me back to > sanity. I had been forced off the path, and now realize just how crazy > it is. > > On Fri, Nov 6, 2009 at 20:19, Craig L Russell <craig.russ...@sun.com> wrote: >>... >> As I thought I said earlier, *any* release that has proper Apache packaging, >> licensing, and notices is fine with me. We've had this discussion in the >> incubator before, for similar reasons, and I think there is consensus that a >> formal review of a podling release is a reasonable gate for graduation. No >> one needs to believe that the release is stable, tested, reliable, etc.; it >> just needs to be reviewed. > > Please let me translate: > > "ANY release is fine, even if that release DOES NOT satisfy the > project's ESTABLISHED LEVELS OF QUALITY. Shoot. All we want is > *something*. Oh, and since it has completely inferior quality, it > doesn't even have to be distributed! See how easy that is! Oh, never > mind, that if we don't put it into the regular distribution channels, > and don't make the regular announcements, then YOU'RE NOT DOING A REAL > APACHE RELEASE." > > Nope. No way. > > The Subversion developers have years of experience releasing code here > at Apache. Personally, I've been involved in releases of httpd and apr > for the past ELEVEN years. Then we can talk about the additional > years/decades of experience brought by Sander, Justin and DLR. Oh, and > did I mention that Garrett was the VP of APR? That he was on the hook > for making releases here at Apache? > > If a relatively new committer on the APR project wanted to make a > release, then they would get handheld by the old-timers. They would > make mistakes, but those would be caught before final release. That > newbie does not come here and subject themselves to the oversight of > the Incubator PMC. They are subject to the APR PMC itself. It makes no > sense to apply hand-holding to a project that already has old-timers. > Forget the hand-holding, and TEACH the arriving project about the > overall guidelines. Point them at the ASF's release guidelines, maybe > note where there are differences from the existing guidelines, and > then let the PMC apply the correct oversight. > > If there are no old-timers, or if the project wants to make a release > *while* in the Incubator? Then sure... apply the release guidelines. > But applying the thumbscrews now is no indicator of future compliance. > At the ASF, we make the PMCs responsible. *LET* them be responsible. > > > The suggestion of a sub-par release, that should be hidden from the > public is just ridiculous on the face of it. It teaches the incoming > podling several things: > > * there are people who follow rules rather than solving a problem > * you will want to route around those people, which means politicking > * satisfying a checklist is more important than teaching > > I don't want to see those principles taught to Subversion. I don't > want to see those taught to ANY podling. > > > The Incubator PMC is here to TEACH podlings. Stop and think before > attempting to apply "rules and procedures". > > -g > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
