On Mon, Nov 9, 2009 at 3:49 PM, Greg Stein <gst...@gmail.com> wrote: > We certainly have no intent to bring Bad Code into the ASF!
I am sure you do. However that is not the issue I'm going against: when Good Code is brought into the ASF in a Bad Way or in a Good Way with Bad Reasoning. I actually like the way you ask for waivers for stuff that is required by the Incubator. But this should be open to any podling, regardless of the number of Members that are associated with the project, and should be founded on hard fact (RAT reports, vote threads), not by pointing at seniority or familiarity. Would a waiver be possible for Diversity (large project dominated by 1 or 2 vendors)? For the minimum required binding votes (small communities of 2 committers)? > In fact, we already know of a couple key points that we're bringing to > legal-discuss. i.e. we're already ahead of the game by doing a review. > We've already got all the IP collected. We've applied standard > headers. We're using ALv2. Then running RAT should not uncover anything out of the ordinary. >> AFAIK releases done by podlings are legally more sound than >> established projects at Apache. Do you consider that a bad thing? > > We have no release planned for the timeframe that I believe we will be > within the Incubator. To force one does not make sense, as I've > stated. Then don't call it a release but a proper (legal) code review. >> 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? > > That is just an unfair and unfounded accusation. I see a lot of finger pointing at the long list of established Members of the ASF that are part of the proposal and using that as the reason not to have to do an incubator release or follow established incubator policies. While I appreciate the stature of the list of committers, I can't help but notice a pattern: "Policy says we have to do X. We don't have to do X because we have N long standing Members of the ASF." This reasoning doesn't fly with me. I'd rather see: "Policy says we have to do X. We already do (or have done) X as can be seen from this and that." Show us the RAT report that has no outstanding issues. That should mitigate any objections to skipping a release (IMO). Podlings go through releases so that we can look at the RAT report (previously we went through the release by hand, thank god for RAT) and ensure all the legal bits are in the right place and contain the right information. >> Have an incubator release? (nah, we are better at releasing because we >> have long standing members) > > Frankly: yeah. You can read my rationale when I ask for a vote. Feel > free to vote against if you feel our waiver is unwarranted, but I do > feel that we're quite well-experienced. > I prefer Leo's "hey, have you checked the RAT output for svn?" than > "you must make a release" kind of arguments. He's providing a helpful > pointer to a tool, rather than directing us into senseless work. Since Leo already pointed out the RAT tool, I didn't see a need. I did see a lot of "We don't have to check our code because we are experienced" argumentation, which I find invalid. I'm an experienced (not as much as you, granted) developer, but that doesn't mean I don't make mistakes, or have all the dots on the i's and /'s in the x's. What you fail to see in your haste to get out of the incubator at breakneck speeds is that the release is purely intended for the legal bits. This is part of the Incubator's charter. Should we vote +1 on graduation based on your experience, or on the hard facts that a RAT report can provide? >> Migrate all subscribers to the mailinglists from one legal >> organization to another? (afaik this is legally forbidden) > > Where did you ever see that we would do that? In the original proposal: "We will work with the Infrastructure team to transfer the subscriber listings to the new destinations." > Since you're already making false accusations, how about I just > clarify for you: this has *already been discussed*. Our plan is to set > up new lists and invite old list members to subscribe to the new one. Great. No problem for me. >> Hosting non-Apache released artifacts at Apache hardware? > > If you're referring to the older releases of Subversion? You bet. They > are all with a compatible license. Have you ever noticed all those > .jar files we host here at Apache? > Those aren't released by us. Or how > about the PCRE software embedded into httpd? Or that copy of Expat > down in apr-util? > > We have already conferred with Infrastructure, and they saw no problem > with hosting old releases on archive.apache.org. I'm just referring to my experience, and that is that software released by podlings built before they came to Apache doesn't belong on Apache hardware. If that is not the case, I stand corrected and will ask to host the old Wicket distributions in archive.apache.org along with the non-Apache Wicket websites. This will make it less confusing for our users. A win for all! >> 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. > Any deviation from the standard process, I intend to be asking for a > specific waiver (much like I did before we even got here!). If > somebody else wants to take shortcuts in the future, then they better > have solid requests for waiving an item. But I believe that is quite > acceptable: if there is a explainable rationale/reason for that waiver > for any podling, then why shouldn't it be made? Would you have considered waiving Wicket's community processes which were already in line with ASF procedures? Did we really have to vote in 2 additional committers before we could graduate? Are the waivers only available for projects with N long time Members of the ASF, or for any project? Would N == 0 be enough? Martijn --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
