On Mon, Nov 9, 2009 at 1: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 key question in my mind is "What tasks does subversion need to undertake as part of its moving to the ASF so that any release it produces conforms to the ASF's policy on releases?". This itself is really part of the whole IP due diligence in bringing any code base here to the ASF IMO. So for example you're going to have to go through the pain of conforming to the policy on license headers for source files and the NOTICE and LICENSE files etc. I would expect that you would do that as part of the incubating process. I don't know how subversion actually creates its source release, but I would assume its a pretty trivial effort to create a an example/internal source distro that could be reviewed. This is what I think Craig was asking and it seemed to me like he was agreeing with your *internal release* suggestion - so I think you did him a big disservice with this rant. The only way reason I can think that you would object to this (because of the effort) is if you didn't plan to sort out subversion to conform to ASF policy before graduation. If you do plan to sort out all these things before graduation then its simply a case of running whatever command(s) you use to create the source distro on subversion's trunk and providing it for people to review. And I assume (and I believe Craig did as well) that that sort of *internal release* would be a pretty trivial effort and not much of a burden to ask. If you don't plan to sort these things out prior to graduation then thats probably the real argument (waiver) you need to get agreement on from the IPMC (rather than release). Niall > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
