Hi Ant, On Aug 19, 2009, at 12:23 AM, ant elder wrote:
On Wed, Aug 19, 2009 at 6:11 AM, Ralph Goers<ralph.go...@dslextreme.com > wrote:On Aug 18, 2009, at 5:13 PM, Joe Schaefer wrote:----- Original Message ----From: Ralph Goers <ralph.go...@dslextreme.com> To: general@incubator.apache.org Sent: Tuesday, August 18, 2009 8:00:00 PM Subject: Re: Making up policy on the fly On Aug 18, 2009, at 4:22 PM, Craig L Russell wrote:So I found it: http://www.apache.org/dev/release.html Please take a look athttp://www.apache.org/dev/release.html#distributing-code-under-several-licenses [1]If this document is not normative, please let me know. Granted, it says"should" and not "must", so if there is a discussion presumably it'sabout whether "should" means "must".Otherwise, let's shut this discussion down and start following the rules.OK then. There is something wrong with how hard that was to find though.Andyou're right, instead of "If An Artifact Contains Code Under SeveralLicenses,Should It Contain Several License Files?" it would be much better if itread "IfAn Artifact Contains Code Under Several Licenses, May It Contain SeveralLicense Files?". However, I think we should pretend it does.It's written the way it is because we are aware that not all Apache projects comply with the recommendation.Being ambiguous is no way to set policy.+1. And i'd go further and say while the ASF does not have a clear policy on something that is an ASF issue then the IPMC should not be trying to make up our own, and, we should be trying to shield poddlings from these ambiguities.
I'd go exactly the other direction.The fact that policy has "should" instead of "must" tells me that best practice is to do the "should" but for historical reasons, it's not a requirement. Historically some PMCs have not done the "should" and we can't go back and change history, but going forward, projects "should" comply.
The incubator should be the place where "should" becomes "must" so as to align newcomers to Apache with best practice. If there's some very good reason for a podling to eschew best practice, then let's hear it.
Craig
If we run into issues of unclear policy then take it to legal-discuss@ or board@ or where ever is appropriate but in the meantime let poddlings release as long as they aren't violating existing policy. We all know that release early release often is good but thats really difficult for poddlings as release votes so often run into these types of problems. One thing I think might help is to change the IPMC poddling release voting process in the same way that the committer voting process was changed recently - allow release votes to be held on the poddling mailing lists and all they need is 3 binding votes from IPMC members and they only need to bring it to general@ if they can't get enough binding votes. Comments? ...ant --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
