[X] -1 for fatal flaws that should cause these bits not to be released:

Looks like we have 5 files missing licensing information.



7 Unknown Licenses

*******************************

Unapproved licenses:

The five files below appear to be missing any kind of licensing
information.    The rest of the files in this directory have licensing
information.


myfaces-core-module-2.1.9/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/_EvalHandlers.js
myfaces-core-module-2.1.9/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/_RuntimeQuirks.js
myfaces-core-module-2.1.9/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/engine/BaseRequest.js
myfaces-core-module-2.1.9/api/src/main/javascript/META-INF/resources/myfaces/_impl/_util/_DomExperimental.js
myfaces-core-module-2.1.9/api/src/main/javascript/META-INF/resources/myfaces/_impl/_util/_ExtLang.js



myfaces-core-module-2.1.9/api/src/main/resources/META-INF/licenses/dojo-LICENSE.TXT

"New" BSD or AFL 2.1.  Bsd is approved, so maybe just add to exclude list.


myfaces-core-module-2.1.9/api/src/main/resources/META-INF/licenses/facelets-LICENSE.txt

APL 2, but unusual format? -- add to exclude list?


Below is the link describing what we need to do to add files to an exclude list.

http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200907.mbox/%[email protected]%3E



On Thu, Sep 6, 2012 at 11:30 PM, Mike Kienenberger <[email protected]> wrote:
> Thanks!  Not sure how I missed that one.   Withdrawing my vote.   I'll
> let you know how it turns out.
>
>
> On Thu, Sep 6, 2012 at 11:20 PM, Leonardo Uribe <[email protected]> wrote:
>> Hi
>>
>> This artifact:
>>
>> https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/core/myfaces-core-module/2.1.9/myfaces-core-module-2.1.9-source-release.zip
>>
>> is the one that allows to build it using maven. In practice, it is a
>> copy of the sources from the svn. This artifact is included also in:
>>
>> https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/core/myfaces-core-assembly/2.1.9/myfaces-core-assembly-2.1.9-src.zip
>>
>> Build it is quite simple: unpack and mvn install.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2012/9/6 Mike Kienenberger <[email protected]>:
>>> So I'm doing the work to vote for a release -- something I haven't
>>> participated in in a very long time.
>>>
>>> Leonardo's key in KEYS - check
>>> .jar.md5 matches - check
>>> .jar.asc.md5 matches - check
>>> .jar.sha1 matches -check
>>> .jar.asc.sha1 matches -check
>>> .asc files mat
>>>
>>> Includes source - check
>>> Source builds --  Not seeing any kind of build system or build instructions.
>>>
>>> Checking our web site only shows how to build from an svn checkout.
>>>
>>> Did we somehow lose the ability to build from our released source when
>>> we switched to maven?
>>> Because unless something has changed this is a big deal.
>>>
>>> http://www.apache.org/dev/release.html#what
>>> ====================
>>> What Must Every ASF Release Contain?
>>>
>>> Every ASF release *must* contain a source package, which must be
>>> sufficient for a user to build and test the release provided they have
>>> access to the appropriate platform and tools.
>>> [...]
>>> What are the ASF requirements on approving a release?
>>>
>>> [...] Before voting +1 PMC members are required to download the signed
>>> source code package, compile it as provided, and test the resulting
>>> executable on their own platform, along with also verifying that the
>>> package contains the required contents.
>>> ====================
>>>
>>> We hit this issue in Cayenne a couple years back and had to do some
>>> work to fix it.
>>>
>>> http://markmail.org/thread/njray5dbazwcdcts
>>>
>>> The natural inclination is to argue about it and try to say it's not
>>> required.   One can read through lots of threads on that if you really
>>> want to satisfy that need.
>>>
>>> But it all comes down to the fact that our "open source" releases need
>>> to be something that someone can modify and build.   And right now,
>>> that isn't doable.  Source control systems come and go.   The ASF
>>> might disappear next year.   Or you might just be some poor guy who,
>>> five years from now, has to work on a project I wrote to fix some
>>> minor bug and find that the particular branch for Myfaces 2.1.9
>>> accidentally got corrupted.  The reasons for why it is done this way
>>> are numerous and worthwhile.   But even if that doesn't sell you on
>>> it, in the end it comes down to being a requirement of a release,
>>> whether or not you agree with it.
>>>
>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201008.mbox/%[email protected]%3E
>>>
>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201008.mbox/%[email protected]%3E
>>>
>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/201008.mbox/%[email protected]%3E
>>>
>>> But don't just take my word on it, read through the 123 messages on
>>> the legal discuss thread :)
>>>
>>> http://markmail.org/thread/njray5dbazwcdcts
>>>
>>>
>>> So at least for now,
>>>
>>>  [X] -1 for fatal flaws that should cause these bits not to be released:
>>>
>>> - Release cannot be built and tested from source.

Reply via email to