metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sirota <jsir...@hortonworks.com>
Subject Re: [VOTE] Release of Metron_0.1BETA_rc3
Date Fri, 19 Feb 2016 17:43:28 GMT
Billie,

What if we created a Jira for our next build to refactor out Mark’s code?  We would then
document that our next release would be contingent upon having that Jira work done.  So for
this release we can have Mark's code as Apache licensed and for the next release we’ll just
refactor it out.  Would that work?

Thanks,
James 



On 2/19/16, 9:25 AM, "Billie Rinaldi" <billie@apache.org> wrote:

>It's definitely possible for software to be distributed under two different
>licenses (for example: http://www.eclipse.org/jetty/licenses.php).  As the
>author, you can correct that license header.  Reading the ICLA again may be
>helpful for clarification, specifically item 2. Grant of Copyright License.
>
>The release vote looks great this time.  I took a look over the source tree
>and saw a few other things that should be corrected before we can make a
>release.  There are many author tags that should be removed from Metron
>code; Apache does not use author tags.  There are many files that do not
>have Apache license headers (see
>http://www.apache.org/legal/src-headers.html).  There also appear to be
>third-party products included.  This is okay as long as they have
>compatible licenses, but in most cases they need to be called out in the
>project's LICENSE or NOTICE file.  The instructions for doing this are
>here: http://www.apache.org/dev/licensing-howto.html.  A quick summary: MIT
>or BSD-licensed things are added to LICENSE, Apache-licensed things might
>need a mention in NOTICE.
>
>
>
>On Fri, Feb 19, 2016 at 7:27 AM, Mark Bittmann <mark@b23.io> wrote:
>
>> Thanks Larry for catching the header on the ansible module. That's my
>> fault for not being more careful. It is not currently part of the Ansible
>> distribution. As Casey pointed out, it is in a PR under review. If it ever
>> made its way into the Ansible product as GPL, then we would remove the file
>> entirely from the Metron codebase since it would be maintained and shipped
>> with Ansible.
>>
>> As the original author, I'm not sure whether I can simply change version
>> in Metron and remove it if/when adopted. If so, the file would then exist
>> in two places at once, as a pending PR to an external project with GPL
>> header and in ASF codebase with ASF license. I'm no lawyer, so I would
>> welcome any feedback as to whether that strategy violates two licenses at
>> once. Another option would be to abandon the module and take this approach
>> for setting up the Ambari cluster:
>> https://github.com/seanorama/ansible-ambari/tree/master/roles/blueprint.
>> You lose some convenience and nicer error reporting. I suppose I could
>> cancel the existing PR, but I do believe there is community value to the
>> module. Whatever we decide, I'll make sure to clean it up this weekend.
>> Thanks again Larry for your oversight and helping us on this process.
>>
>>
>>
>>
>> On 2/19/16, 9:58 AM, "Casey Stella" <cestella@gmail.com> wrote:
>>
>> >No problem!  We're on our way to the next RC now with the other issues.
>> >But, before that can happen, I wanted to give a bit more context to the
>> GPL
>> >issue.
>> >
>> >It appears that the file in question was submitted to ansible and is in
>> the
>> >"community review" stage, so it has not been merged with ansible.
>> Relevant
>> >PR: https://github.com/ansible/ansible-modules-extras/pull/1226
>> >It was subsequently contributed here.
>> >
>> >I expect this means that it's not as simple as just asking Mark to change
>> >the license, but I don't know.  Any guidance would be greatly appreciated.
>> >
>> >Casey
>> >
>> >
>> >On Fri, Feb 19, 2016 at 9:39 AM, larry mccay <lmccay@apache.org> wrote:
>> >
>> >> Thanks for the verification instructions, Casey!
>> >> I strongly encourage folks to manually test in this way as well.
>> >> Then indicate along with your vote exactly what was tested.
>> >> This allows for ensuring that the integration test is actually working
>> >> properly and exactly what sort of functional testing coverage there was
>> for
>> >> the vote.
>> >>
>> >> The KEYS file within the source tree...
>> >> I'm not sure whether it will create any actual problem but it certainly
>> >> becomes something that could get out of sync with what is used to verify
>> >> the signatures. Keep in mind that this is used to ensure that the
>> release
>> >> archive hasn't been tampered with. If for whatever reason someone uses
>> the
>> >> KEYS file within the source archive to verify the signature it would
>> >> invalidate the test. Tampering with the archive and replacing the KEYS
>> file
>> >> with one that will verify would not be detectable.
>> >>
>> >> I don't have enough context regarding the GPL header. It claims that the
>> >> file is part of ansible with which is apparently GPL'd technology and
>> >> cannot be redistributed in an ASL release. Including such a file
>> requires
>> >> the entire project to be GPL. If this file and any others truly are from
>> >> ansible then they need to be removed.
>> >>
>> >> You are making good progress toward getting this release out!
>> >> The first one is always the toughest.
>> >> Once we get all these painful nuances taken care of subsequent releases
>> >> will be much easier.
>> >> It is important to get it as right as possible the first release - so
>> that
>> >> it is easier going forward.
>> >>
>> >>
>> >> On Fri, Feb 19, 2016 at 9:13 AM, Casey Stella <cestella@gmail.com>
>> wrote:
>> >>
>> >> > At least regarding the Keys, we were following Apache Wave's (
>> >> > https://github.com/apache/incubator-wave)  model who kept their keys
>> in
>> >> > the
>> >> > source repo.  I figured it would be a good idea so it was a known
>> place.
>> >> > Is there harm in keeping it there?  Certainly, we'll want to merge
the
>> >> > existing keys file with Owen and Billie's keys in.
>> >> >
>> >> > Regarding verification, we have taken some pains to have an end-to-end
>> >> > integration tests as a junit test available this release, so at the
>> very
>> >> > least ensure that mvn integration-test runs (though this is
>> prerequisite
>> >> > for any commit).
>> >> > That being said, running vagrant up from
>> >> > the deployment/vagrant/singlenode-vagrant/ directory will spin up a
>> >> single
>> >> > node VM with the software installed and running so you can play with
>> it
>> >> > further.  I would warn you that it's a bit overcommitted
>> resource-wise at
>> >> > the moment and components are prone to crash due to lack of memory,
>> so be
>> >> > aware of that.
>> >> >
>> >> > What I normally do is:
>> >> >
>> >> >    - stop all of the storm topologies other than pcap
>> >> >    - run some traffic through there by pinging or wget'ing
>> >> >    - Check that I'm seeing values in the elastic search index
>> >> >       - Check to see that an index was created: curl
>> >> >       http://node1:9200/_cat/indices?v
>> >> >       - Check indexed values (assuming index name is
>> >> >       pcap_index_2016.02.13.06 is the index): curl "
>> >> >
>> >> >
>> >>
>> http://node1:9200/pcap_index_2016.02.13.06/_search?pretty=true&q=*:*&size=28000
>> >> > "
>> >> >       | python -m json.tool | vi -
>> >> >       - Check that pcap raw data is making it to hbase via the hbase
>> >> shell
>> >> >    in the pcap_test table
>> >> >
>> >> > Generally this is what's being done in the integration test called
>> >> > PCapIntegrationTest.
>> >> >
>> >> > The missing headers should be corrected, obviously, before the next
>> RC.
>> >> >
>> >> > I am not sure what to go through to about the GPL license on the
>> >> > ambari_cluster_state.py.  Mark committed it, is there more to be done
>> >> than
>> >> > have Mark agree to re-license with Apache or is there some other more
>> >> > official legal process that we have to go through?
>> >> >
>> >> > Casey
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Feb 18, 2016 at 8:38 PM, larry mccay <lmccay@apache.org>
>> wrote:
>> >> >
>> >> > > Is there any Metron specific functional testing that can be
>> performed
>> >> as
>> >> > > criteria for giving a +1?
>> >> > > Can we use the ansible scripts to fire up a deployment and manually
>> >> check
>> >> > > anything?
>> >> > >
>> >> > > It's usually good to be able to specific a +1 and the list of
things
>> >> that
>> >> > > you tested.
>> >> > >
>> >> > > Metro should have a staging directory inside of:
>> >> > > https://dist.apache.org/repos/dist/dev/incubator/.
>> >> > >
>> >> > > I notice that there is already a release dir:
>> >> > > https://dist.apache.org/repos/dist/release/incubator/metron/ and
>> that
>> >> > > within this there is a KEYS file with Billie's and Owen's keys
>> included
>> >> > > this is not the KEYS file used for this release candidate which
may
>> be
>> >> > okay
>> >> > > but having Billie's and Owen's in there help it be trusted by
more
>> >> folks
>> >> > > when verifying the signatures.
>> >> > >
>> >> > > I am not sure that you want the KEYS file inside the source tree.
>> >> > >
>> >> > > There are missing Apache headers in a many files.
>> >> > > All scripts, config files, descriptors must have Apache headers.
>> >> > >
>> >> > > ambari_cluster_state.py has the following GNU license header which
>> I do
>> >> > not
>> >> > > believe ASL friendly:
>> >> > >
>> >> > > # Author: Mark Bittmann (https://github.com/mbittmann)
>> >> > > # This file is part of Ansible
>> >> > > #
>> >> > > # Ansible is free software: you can redistribute it and/or modify
>> >> > > # it under the terms of the GNU General Public License as published
>> by
>> >> > > # the Free Software Foundation, either version 3 of the License,
or
>> >> > > # (at your option) any later version.
>> >> > > #
>> >> > > # Ansible is distributed in the hope that it will be useful,
>> >> > > # but WITHOUT ANY WARRANTY; without even the implied warranty
of
>> >> > > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> >> > > # GNU General Public License for more details.
>> >> > > #
>> >> > > # You should have received a copy of the GNU General Public License
>> >> > > # along with Ansible.  If not, see <http://www.gnu.org/licenses/>.
>> >> > >
>> >> > > Unfortunately, I have to give a -1 until these issues are corrected
>> -
>> >> or
>> >> > > someone corrects my understanding.
>> >> > >
>> >> > >
>> >> > >
>> >> > > On Thu, Feb 18, 2016 at 6:05 PM, Charles Porter <
>> >> > > opensource.charles@gmail.com> wrote:
>> >> > >
>> >> > > > +1
>> >> > > >
>> >> > > > On Thu, Feb 18, 2016 at 2:39 PM, James Sirota <
>> >> jsirota@hortonworks.com
>> >> > >
>> >> > > > wrote:
>> >> > > >
>> >> > > > > A tag has been created for Metron_0.1BETA_rc3:
>> >> > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=shortlog;h=refs/tags/Metron_0.1BETA_rc3
>> >> > > > >
>> >> > > > > With a Git hash:
>> >> > > > > 5ceee2a44ff777d3e980406c4a70efc9297e5350
>> >> > > > >
>> >> > > > > And a KEYS file:
>> >> > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-metron.git;a=blob_plain;f=KEYS;hb=refs/heads/Metron_0.1BETA
>> >> > > > >
>> >> > > > > And a staging directory:
>> >> > > > > http://people.apache.org/~jsirota/metron/
>> >> > > > >
>> >> > > > > Please verify the release and vote.  The vote will close
on
>> Monday,
>> >> > > Feb.
>> >> > > > > 22nd.
>> >> > > > >
>> >> > > > > Instructions for evaluating the build are posted here
under
>> >> “Release
>> >> > > > > Checklist":
>> >> > > > > http://incubator.apache.org/guides/releasemanagement.html
>> >> > > > >
>> >> > > > > Please vote +1 if you approve and –1 if you do not
approve.
>> Also,
>> >> > > please
>> >> > > > > indicate if your vote is binding
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
Mime
View raw message