Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

[Dan Kirkwood]

+1

I checked:
- git tag verified
- pgp signature matched
- checksum matched
- all components build with `./pkg -v`
- TO install and run on fresh Centos 7.4 VM


On Mon, May 14, 2018 at 2:52 PM Jeff Elsloo  wrote:

> +1
>
> Signature validates and tests performed previously were unaffected by
> the latest RC.
> --
> Thanks,
> Jeff
>
>
> On Fri, May 11, 2018 at 12:22 PM, Robert Butts  wrote:
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC6
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> >
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0...RELEASE-2.2.0-RC6
> >
> > This corresponds to git:
> >  Hash: 8f4d1ee2aa25000a9d0e17bbf85286c4a7264eab
> >  Tag: RELEASE-2.2.0-RC6
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC6
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC6
> >
> >
> >
> > Thanks!
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

[Dan Kirkwood]

I just edited it -- hopefully that'll take care of if for next time...

On Sun, May 13, 2018 at 12:21 PM Robert Butts <robert.o.bu...@gmail.com>
wrote:

> Yes, sorry, I used the template email. We were instructed not to create MD5
> or SHA1 files anymore. We need to update the template in the wiki.
>
> On Sun, May 13, 2018 at 12:07 PM, Dan Kirkwood <dang...@gmail.com> wrote:
>
> > Hey,  Rob,  I'm not voting yet since I've only verified the checksums and
> > signature, but the email still mentions md5 and sha1 checksums -- only
> > sha512 checksum and pgp signature are there.  I think the correct files
> are
> > provided and the email is incorrect.
> >
> > -dan
> >
> > On Fri, May 11, 2018 at 12:22 PM Robert Butts <r...@apache.org> wrote:
> >
> > > Hello All,
> > >
> > > I've prepared a release for v2.2.0-RC6
> > >
> > > The vote is open for at least 72 hours and passes if a majority of at
> > least
> > > 3 +1 PPMC votes are cast.
> > >
> > > [ ] +1 Approve the release
> > >
> > > [ ] -1 Do not release this package because ...
> > >
> > > Changes since 2.1.0:
> > >
> > > https://github.com/apache/incubator-trafficcontrol/
> > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC6
> > >
> > > This corresponds to git:
> > >  Hash: 8f4d1ee2aa25000a9d0e17bbf85286c4a7264eab
> > >  Tag: RELEASE-2.2.0-RC6
> > >
> > > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC6
> > >
> > > My code signing key is available here:
> > > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> > >
> > > Make sure you refresh from a key server to get all relevant signatures.
> > >
> > > The source .tar.gz file, pgp signature (.asc signed with my key from
> > > above), md5 and sha1 checksums are provided here:
> > >
> > > https://dist.apache.org/repos/dist/dev/incubator/
> > trafficcontrol/2.2.0/RC6
> > >
> > >
> > >
> > > Thanks!
> > >
> >
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

[Dan Kirkwood]

Hey,  Rob,  I'm not voting yet since I've only verified the checksums and
signature, but the email still mentions md5 and sha1 checksums -- only
sha512 checksum and pgp signature are there.  I think the correct files are
provided and the email is incorrect.

-dan

On Fri, May 11, 2018 at 12:22 PM Robert Butts  wrote:

> Hello All,
>
> I've prepared a release for v2.2.0-RC6
>
> The vote is open for at least 72 hours and passes if a majority of at least
> 3 +1 PPMC votes are cast.
>
> [ ] +1 Approve the release
>
> [ ] -1 Do not release this package because ...
>
> Changes since 2.1.0:
>
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0...RELEASE-2.2.0-RC6
>
> This corresponds to git:
>  Hash: 8f4d1ee2aa25000a9d0e17bbf85286c4a7264eab
>  Tag: RELEASE-2.2.0-RC6
>
> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC6
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), md5 and sha1 checksums are provided here:
>
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC6
>
>
>
> Thanks!
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC4

[Dan Kirkwood]

+1

I tested:
- signature and checksum good
- `./pkg -v` builds all components successfully
- traffic_ops installs on clean Centos 7 VM
- postinstall properly configures
- a couple of basic traffiic_ops calls return proper json output


On Mon, Apr 9, 2018 at 3:58 PM, David Neuman 
wrote:

> +1
> I tested the following:
> - building with the pkg command
> - signatures
> - checksums (were we supposed to get rid of md5?  I must have missed that)
> - installed and started traffic_stats
>
>
> On Wed, Apr 4, 2018 at 11:04 AM, Robert Butts  wrote:
>
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC4
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-2.1.0
> .
> > ..
> > RELEASE-2.2.0-RC4
> >
> > This corresponds to git:
> >  Hash: 45151f8e518fe92dfa64c7311b877cb13299debc
> >  Tag: RELEASE-2.2.0-RC4
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC4
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), and sha512 checksum are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC4
> >
> >
> >
> > Thanks!
> >
>

Re: [VOTE] Resolution for Traffic Control graduation to TLP

[Dan Kirkwood]

+1

On Mon, Apr 2, 2018 at 2:12 PM, Dave Neuman <neu...@apache.org> wrote:

> +1
>
> On Mon, Apr 2, 2018 at 2:11 PM, David Neuman <david.neuma...@gmail.com>
> wrote:
>
> > Dear Traffic Control community members:
> >
> > I would like to call a vote on the resolution for Traffic Control to
> > graduate from to an Apache TLP.  We have already voted on whether or not
> we
> > should start the graduation process [1] and this is the next step.
> Please
> > see the resolution below and vote as follows:
> >
> > [ ] +1 Graduate Traffic Control from the incubator
> > [ ] +0 No Opinion
> > [ ] -1 Do not graduate Traffic Control from the incubator (please provide
> > a reason)
> >
> > The vote is open for a minimum of 72 hours and will need at least 3 more
> > +1 votes than -1 votes from PMC members to succeed.
> >
> > If this VOTE succeeds, a similar VOTE will be started on the
> > gene...@incubator.apache.org mailing list. If that VOTE succeeds, a
> > resolution will be included in the next Apache Board Meeting.
> >
> > Please feel free to reach out with any questions.
> >
> > Thanks,
> > Dave
> >
> > [1] https://lists.apache.org/thread.html/fb1fae0785feb6568cef6deb6fa207
> > 23eba54ed63a445462d44564d3@%3Cdev.trafficcontrol.apache.org%3E
> >
> > -
> >
> > Establish the Apache Traffic Control Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best interests of
> > the Foundation and consistent with the Foundation's purpose to establish
> > a Project Management Committee charged with the creation and maintenance
> > of open-source software, for distribution at no charge to the public,
> > related to building, monitoring, configuring, and provisioning a large
> > scale content delivery network (CDN)..
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache Traffic Control Project", be and
> > hereby is established pursuant to Bylaws of the Foundation; and be it
> > further
> >
> > RESOLVED, that the Apache Traffic Control Project be and hereby is
> > responsible for the creation and maintenance of software related to
> > building, monitoring, configuring, and provisioning a large scale
> > content delivery network (CDN).; and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Traffic Control" be
> > and hereby is created, the person holding such office to serve at the
> > direction of the Board of Directors as the chair of the Apache Traffic
> > Control Project, and to have primary responsibility for management of
> > the projects within the scope of responsibility of the Apache Traffic
> > Control Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and hereby are
> > appointed to serve as the initial members of the Apache Traffic Control
> > Project:
> >
> >  * Dan Kirkwood   <dang...@apache.org>
> >  * David Neuman   <neu...@apache.org>
> >  * Dewayne Richardson <dewr...@apache.org>
> >  * Eric Covener   <cove...@apache.org>
> >  * Eric Friedrich <fri...@apache.org>
> >  * Hank Beatty<hbea...@apache.org>
> >  * Jan van Doorn  <j...@apache.org>
> >  * Jeff Elsloo<els...@apache.org>
> >  * Jeremy Mitchell<mitchell...@apache.org>
> >  * Leif Hedstrom  <zw...@apache.org>
> >  * Mark Torluemke <mtorlue...@apache.org>
> >  * Phil Sorber<sor...@apache.org>
> >  * Steve Malenfant<smalenf...@apache.org>
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Neuman be appointed
> > to the office of Vice President, Apache Traffic Control, to serve in
> > accordance with and subject to the direction of the Board of Directors
> > and the Bylaws of the Foundation until death, resignation, retirement,
> > removal or disqualification, or until a successor is appointed; and be
> > it further
> >
> > RESOLVED, that the initial Apache Traffic Control PMC be and hereby is
> > tasked with the creation of a set of bylaws intended to encourage open
> > development and increased participation in the Apache Traffic Control
> > Project; and be it further
> >
> > RESOLVED, that the Apache Traffic Control Project be and hereby is
> > tasked with the migration and rationalization of the Apache Incubator
> > Traffic Control podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > Traffic Control podling encumbered upon the Apache Incubator PMC are
> > hereafter discharged.
> >
> >
> >
>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

[Dan Kirkwood]

Hank, fyi -- from the top level of trafficcontrol, `./pkg -v` will build
all components.

-dan

On Thu, Mar 8, 2018 at 6:34 AM, Hank Beatty  wrote:

> +1
>
> Lab Testing:
>
> - Docker build - Could not figure out how to get all components to build
> at once
> - build/build.sh on CentOS 6 - all components built successfully
> - Upgraded Traffic Monitor (2.2.0.d7e588 -> 2.2.0.6ea850)
>   - Could pull up UI and it connects to all cache servers
> - Upgraded Traffic Router (2.2.0.d7e588 -> 2.2.0.6ea850)
>   - Could connect to : and crs/stats looked correct
> - Upgraded Traffic Stats (2.2.0.d7e588 -> 2.2.0.6ea850) CentOS 6
> - Upgraded Traffic Ops ORT
>   - mid cache "report" and "badass" mode seem to work correctly
>   - edge cache "report" and "badass" mode seem to work correctly
> - Tested DNS DS and works correctly
>
> On 03/05/2018 01:25 PM, Robert Butts wrote:
>
>> Hello All,
>>
>> I've prepared a release for v2.2.0-RC2
>>
>> The vote is open for at least 72 hours and passes if a majority of at
>> least
>> 3 +1 PPMC votes are cast.
>>
>> [ ] +1 Approve the release
>>
>> [ ] -1 Do not release this package because ...
>>
>> Changes since 2.1.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/
>> RELEASE-2.1.0...RELEASE-2.2.0-RC2
>>
>> This corresponds to git:
>>   Hash: 6ea85056a1a69973be4a74b82d602df29f21f42d
>>   Tag: RELEASE-2.2.0-RC2
>>
>> Which can be verified with the following: git tag -v RELEASE-2.2.0-RC2
>>
>> My code signing key is available here:
>> http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
>>
>> Make sure you refresh from a key server to get all relevant signatures.
>>
>> The source .tar.gz file, pgp signature (.asc signed with my key from
>> above), md5 and sha1 checksums are provided here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.2.0/RC2
>>
>>
>> Thanks!
>>
>>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

[Dan Kirkwood]

+1 -- I checked:

- hashes and signature good
- builds all from `./pkg -v`
- TO rpm installs cleanly on a fresh VM
- TO basic functionality works (no extensive testing..)


On Wed, Mar 7, 2018 at 7:00 AM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:

> +1
>
> I checked the following:
> - Release hashes and signatures good
> - Release builds via pkg
> - TO, TR, TM fresh install and start/retrieve config
> - Looked through RAT
>
> Nitpick in the below email: the SHA checksum is a SHA-512 not a SHA-1
>
> —Eric
>
>
>
> > On Mar 5, 2018, at 1:25 PM, Robert Butts  wrote:
> >
> > Hello All,
> >
> > I've prepared a release for v2.2.0-RC2
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> least
> > 3 +1 PPMC votes are cast.
> >
> > [ ] +1 Approve the release
> >
> > [ ] -1 Do not release this package because ...
> >
> > Changes since 2.1.0:
> > https://github.com/apache/incubator-trafficcontrol/
> compare/RELEASE-2.1.0...RELEASE-2.2.0-RC2
> >
> > This corresponds to git:
> > Hash: 6ea85056a1a69973be4a74b82d602df29f21f42d
> > Tag: RELEASE-2.2.0-RC2
> >
> > Which can be verified with the following: git tag -v RELEASE-2.2.0-RC2
> >
> > My code signing key is available here:
> > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The source .tar.gz file, pgp signature (.asc signed with my key from
> > above), md5 and sha1 checksums are provided here:
> >
> > https://dist.apache.org/repos/dist/dev/incubator/
> trafficcontrol/2.2.0/RC2
> >
> >
> > Thanks!
>
>

Re: Github PR/Issues Format Templates

[Dan Kirkwood]

Chris,

"Perfect is the enemy of good".The point here is to make the PR
description good enough to work with,  not perfect.   I appreciate what
you're trying to get to,  but from experience, it's not realistic.

-dan

On Wed, Feb 28, 2018 at 1:31 PM, Chris Lemmons <alfic...@gmail.com> wrote:

> `What effect should I expect to see from this change?`
>
> This is a perfect question, and one that absolutely needs to be
> answered. But either
>
> a) it is answered already in the commit message; or
> b) the commit message is insufficient and needs to be `git -amend`ed.
>
> I definitely wouldn't want a PR that contained that information only
> in the PR body,
> and there's not a whole lot of value in asking them to re-type it. The
> "copy/paste" thing
> at the top is already a bit of duplication anyway.
>
> On Wed, Feb 28, 2018 at 11:03 AM, Dan Kirkwood <dang...@gmail.com> wrote:
> > followup: rather than
> >`What is the best way to verify this PR? `
> >
> > what about
> >
> > `What effect should I expect to see from this change?`
> >
> > On Wed, Feb 28, 2018 at 10:25 AM, Dan Kirkwood <dang...@gmail.com>
> wrote:
> >
> >> +1 on keeping it short and to the point...
> >>
> >> On Wed, Feb 28, 2018 at 10:14 AM, Jeremy Mitchell <
> mitchell...@gmail.com>
> >> wrote:
> >>
> >>> Chris, I really wanted the PR template to be less daunting and super
> short
> >>> and to the point. It's intention is to give a super quick summary of
> >>> what's
> >>> included in this PR to help the merger...
> >>>
> >>> Example:
> >>>
> >>>  What does this PR do? Is there a related Github issue?
> >>>
> >>> "See Issue #1245" or "This PR cascade deletes all delivery service
> regexes
> >>> when a delivery service is deleted"
> >>>
> >>>  What is the best way to verify this PR? <-- IMO this is really
> >>> important for the merger so I know how to "test" or "verify" the
> >>> functionality.
> >>>
> >>> Hit the DELETE /api/1.3/deliveryservices/:id endpoint and ensure all
> >>> entries in the deliveryservice_regex table are deleted for that
> delivery
> >>> service.
> >>>
> >>>  Does your PR include any of the following?
> >>>
> >>> - [ ] Tests
> >>> - [ ] Documentation
> >>> - [X] CHANGELOG.md entry
> >>>
> >>> ^^ I wasn't trying to imply that those last things were required. I
> just
> >>> wanted to provide a checklist that might be helpful for the contributer
> >>> and
> >>> the merger. For example, I always for get to look for a CHANGELOG.md
> >>> entry...
> >>>
> >>> Jeremy
> >>>
> >>>
> >>> On Tue, Feb 27, 2018 at 9:47 PM, Chris Lemmons <alfic...@gmail.com>
> >>> wrote:
> >>>
> >>> > If there's a relevant GitHub issue, that should be noted in the
> >>> > check-in comment, I think. Same for "what does it do?" I don't
> usually
> >>> > want to spell out steps for someone to verify my stuff because those
> >>> > are the steps that I took to verify it. The PR is so you can see the
> >>> > things I didn't see. And the commit list will make the presence of
> >>> > tests, documentation, and a changelog entry really obvious.
> >>> >
> >>> > Taking yours and reformatting a bit, what if we did something like
> this?
> >>> >
> >>> > ...
> >>> >
> >>> > *Describe your PR:* _(copy/paste from changeset comments is
> >>> encouraged!)_
> >>> >
> >>> >
> >>> >
> >>> > *Quick Checklist:*
> >>> >
> >>> > - [ ] Each commit message tells you everything you need to know about
> >>> > the change. (Squashing can help with this.)
> >>> > - [ ] If applicable, the commit message mentions the appropriate
> issue
> >>> > number.
> >>> > - [ ] This PR does *not* fix a serious security flaw. (Read more:
> >>> > www.apache.org/security )
> >>> > - [ ] Automatic code formatters (like gofmt) have been run.
> >>> >
> >>> > *Tests:*
> >>> >
> >>> > - [ ] Are not necessary

Re: Github PR/Issues Format Templates

[Dan Kirkwood]

followup: rather than
   `What is the best way to verify this PR? `

what about

`What effect should I expect to see from this change?`

On Wed, Feb 28, 2018 at 10:25 AM, Dan Kirkwood <dang...@gmail.com> wrote:

> +1 on keeping it short and to the point...
>
> On Wed, Feb 28, 2018 at 10:14 AM, Jeremy Mitchell <mitchell...@gmail.com>
> wrote:
>
>> Chris, I really wanted the PR template to be less daunting and super short
>> and to the point. It's intention is to give a super quick summary of
>> what's
>> included in this PR to help the merger...
>>
>> Example:
>>
>>  What does this PR do? Is there a related Github issue?
>>
>> "See Issue #1245" or "This PR cascade deletes all delivery service regexes
>> when a delivery service is deleted"
>>
>>  What is the best way to verify this PR? <-- IMO this is really
>> important for the merger so I know how to "test" or "verify" the
>> functionality.
>>
>> Hit the DELETE /api/1.3/deliveryservices/:id endpoint and ensure all
>> entries in the deliveryservice_regex table are deleted for that delivery
>> service.
>>
>>  Does your PR include any of the following?
>>
>> - [ ] Tests
>> - [ ] Documentation
>> - [X] CHANGELOG.md entry
>>
>> ^^ I wasn't trying to imply that those last things were required. I just
>> wanted to provide a checklist that might be helpful for the contributer
>> and
>> the merger. For example, I always for get to look for a CHANGELOG.md
>> entry...
>>
>> Jeremy
>>
>>
>> On Tue, Feb 27, 2018 at 9:47 PM, Chris Lemmons <alfic...@gmail.com>
>> wrote:
>>
>> > If there's a relevant GitHub issue, that should be noted in the
>> > check-in comment, I think. Same for "what does it do?" I don't usually
>> > want to spell out steps for someone to verify my stuff because those
>> > are the steps that I took to verify it. The PR is so you can see the
>> > things I didn't see. And the commit list will make the presence of
>> > tests, documentation, and a changelog entry really obvious.
>> >
>> > Taking yours and reformatting a bit, what if we did something like this?
>> >
>> > ...
>> >
>> > *Describe your PR:* _(copy/paste from changeset comments is
>> encouraged!)_
>> >
>> >
>> >
>> > *Quick Checklist:*
>> >
>> > - [ ] Each commit message tells you everything you need to know about
>> > the change. (Squashing can help with this.)
>> > - [ ] If applicable, the commit message mentions the appropriate issue
>> > number.
>> > - [ ] This PR does *not* fix a serious security flaw. (Read more:
>> > www.apache.org/security )
>> > - [ ] Automatic code formatters (like gofmt) have been run.
>> >
>> > *Tests:*
>> >
>> > - [ ] Are not necessary.
>> > - [ ] Would be helpful, but aren't in this PR.
>> > - [ ] Are present, but incomplete.
>> > - [ ] Are included.
>> >
>> > *Doc updates:*
>> >
>> > - [ ] Are not necessary.
>> > - [ ] Would be helpful, but aren't in this PR.
>> > - [ ] Are present, but incomplete.
>> > - [ ] Are included.
>> >
>> > *If there's no update to CHANGELOG.md, why not?*
>> >
>> > *Does this break backward compatibility?*
>> >
>> > *Is there anyone specific that ought to take a look at this?*
>> >
>> > ...
>> >
>> > We want to be friendly to committers, while still getting good
>> > information for checking PRs. I could be easily convinced that the
>> > "Tests" or "Doc updates" sections in there are too long, but I think
>> > it should be clear that a potential committer can offer up some code
>> > without hitting 100% on tests, docs, and such.
>> >
>> > On Tue, Feb 27, 2018 at 1:24 PM, Jeremy Mitchell <mitchell...@gmail.com
>> >
>> > wrote:
>> > > How about something like this for a PR template?
>> > >
>> > >  What does this PR do? Is there a relevant Github issue?
>> > >
>> > >
>> > >  What is the best way to verify this PR?
>> > >
>> > >
>> > >  Does your PR include any of the following?
>> > >
>> > > - [ ] Tests
>> > > - [ ] Documentation
>> > > - [ ] CHANGELOG.md entry
>> > >
>> > > On Tue, Feb 27, 2018 at 10:

Re: Github PR/Issues Format Templates

[Dan Kirkwood]

+1 on keeping it short and to the point...

On Wed, Feb 28, 2018 at 10:14 AM, Jeremy Mitchell 
wrote:

> Chris, I really wanted the PR template to be less daunting and super short
> and to the point. It's intention is to give a super quick summary of what's
> included in this PR to help the merger...
>
> Example:
>
>  What does this PR do? Is there a related Github issue?
>
> "See Issue #1245" or "This PR cascade deletes all delivery service regexes
> when a delivery service is deleted"
>
>  What is the best way to verify this PR? <-- IMO this is really
> important for the merger so I know how to "test" or "verify" the
> functionality.
>
> Hit the DELETE /api/1.3/deliveryservices/:id endpoint and ensure all
> entries in the deliveryservice_regex table are deleted for that delivery
> service.
>
>  Does your PR include any of the following?
>
> - [ ] Tests
> - [ ] Documentation
> - [X] CHANGELOG.md entry
>
> ^^ I wasn't trying to imply that those last things were required. I just
> wanted to provide a checklist that might be helpful for the contributer and
> the merger. For example, I always for get to look for a CHANGELOG.md
> entry...
>
> Jeremy
>
>
> On Tue, Feb 27, 2018 at 9:47 PM, Chris Lemmons  wrote:
>
> > If there's a relevant GitHub issue, that should be noted in the
> > check-in comment, I think. Same for "what does it do?" I don't usually
> > want to spell out steps for someone to verify my stuff because those
> > are the steps that I took to verify it. The PR is so you can see the
> > things I didn't see. And the commit list will make the presence of
> > tests, documentation, and a changelog entry really obvious.
> >
> > Taking yours and reformatting a bit, what if we did something like this?
> >
> > ...
> >
> > *Describe your PR:* _(copy/paste from changeset comments is encouraged!)_
> >
> >
> >
> > *Quick Checklist:*
> >
> > - [ ] Each commit message tells you everything you need to know about
> > the change. (Squashing can help with this.)
> > - [ ] If applicable, the commit message mentions the appropriate issue
> > number.
> > - [ ] This PR does *not* fix a serious security flaw. (Read more:
> > www.apache.org/security )
> > - [ ] Automatic code formatters (like gofmt) have been run.
> >
> > *Tests:*
> >
> > - [ ] Are not necessary.
> > - [ ] Would be helpful, but aren't in this PR.
> > - [ ] Are present, but incomplete.
> > - [ ] Are included.
> >
> > *Doc updates:*
> >
> > - [ ] Are not necessary.
> > - [ ] Would be helpful, but aren't in this PR.
> > - [ ] Are present, but incomplete.
> > - [ ] Are included.
> >
> > *If there's no update to CHANGELOG.md, why not?*
> >
> > *Does this break backward compatibility?*
> >
> > *Is there anyone specific that ought to take a look at this?*
> >
> > ...
> >
> > We want to be friendly to committers, while still getting good
> > information for checking PRs. I could be easily convinced that the
> > "Tests" or "Doc updates" sections in there are too long, but I think
> > it should be clear that a potential committer can offer up some code
> > without hitting 100% on tests, docs, and such.
> >
> > On Tue, Feb 27, 2018 at 1:24 PM, Jeremy Mitchell 
> > wrote:
> > > How about something like this for a PR template?
> > >
> > >  What does this PR do? Is there a relevant Github issue?
> > >
> > >
> > >  What is the best way to verify this PR?
> > >
> > >
> > >  Does your PR include any of the following?
> > >
> > > - [ ] Tests
> > > - [ ] Documentation
> > > - [ ] CHANGELOG.md entry
> > >
> > > On Tue, Feb 27, 2018 at 10:46 AM, Jeremy Mitchell <
> mitchell...@gmail.com
> > >
> > > wrote:
> > >
> > >> With an issue and/or pr template, we will have 6/6 items checked:
> > >>
> > >> https://github.com/apache/incubator-trafficcontrol/community
> > >>
> > >> I actually think PR templates would be quite helpful. As a
> > >> committer/merger, it would be nice to know what problem the PR is
> > solving
> > >> and how to verify the functionality. A PR template could also help
> > >> contributors ensure that their PRs are complete. I.e. does this PR
> > includes
> > >> tests, documentation, etc.
> > >>
> > >> I'll take a stab at a couple of templates and run them by the group.
> > >>
> > >> Jeremy
> > >>
> > >> On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons 
> > wrote:
> > >>
> > >>> I'm +1 on Issue Templates, for sure. I don't know that PR templates
> > >>> are quite as critical, but it might be nice to have a reminder in
> > >>> there about verifying that the changelog is updated if necessary and
> > >>> documentation for new features is present. If the PR Template
> > >>> overwrites the default comment that you get from the commit body, it
> > >>> might be more annoying than valuable, though.
> > >>>
> > >>> I'm also +1 on hiding these particular files in a .github directory.
> > >>> Unlike CONTRIBUTING and README, they don't provide all that much
> > >>> 

Re: [VOTE] CHANGELOG.md file (second try)

[Dan Kirkwood]

+1

On Tue, Feb 27, 2018 at 2:50 PM, Jeremy Mitchell 
wrote:

> I like that format. Bullets seems nice and simple with external links where
> more info is required.
>
> I would be in favor of a PR to add these sections so it's easy for the next
> person to add a bullet to the relevant section.
>
> On Tue, Feb 27, 2018 at 2:15 PM, Rawlin Peters 
> wrote:
>
> > Hey folks,
> >
> > So I used the influxdb changelog as an example format, but @dew has
> > shown me this popular project for changelog convention:
> > http://keepachangelog.com/en/1.0.0/. For example see the project
> > changelog: https://github.com/olivierlacan/keep-a-changelog/
> > blob/master/CHANGELOG.md.
> >
> > Since we now have a changelog, it would be best to have a standard,
> > agreed-upon format for it so that we can keep it consistent for every
> > release.
> >
> > Basically it means every release has its own section (with an
> > "unreleased" section at the top), and everything will be
> > bullet-pointed underneath one of these sections for every release:
> > - "Added" for new features.
> > - "Changed" for changes in existing functionality.
> > - "Deprecated" for soon-to-be removed features.
> > - "Removed" for now removed features.
> > - "Fixed" for any bug fixes.
> > - "Security" in case of vulnerabilities.
> >
> > For example with my per-DS routing name upgrade notes currently in the
> > changelog, I would add that to the "Added" section and link to the
> > upgrade notes in our docs.
> >
> >  What do you all think? All in favor of accepting this keepachangelog
> > format?
> >
> > - Rawlin
> >
> >
> >
> > On Thu, Feb 8, 2018 at 2:29 PM, Rawlin Peters 
> > wrote:
> > > I went ahead and created one:
> > > https://github.com/apache/incubator-trafficcontrol/pull/1865. Please
> > > review and merge if you are okay with the current format. I'm not sure
> > > if we want to go back and add a list of all the new features in 2.2 or
> > > not, but please add to the CHANGELOG.md file if you have any pending
> > > release notes like 2.2 upgrade gotchas you'd like to get in.
> > >
> > > Thanks,
> > > Rawlin
> > >
> > > On Wed, Feb 7, 2018 at 4:07 PM, Dave Neuman  wrote:
> > >> Hey Rawlin,
> > >> I think Steve was starting to work on one, so we will see what he
> says.
> > >> If he doesn't have one started, I think you can go ahead and create
> one.
> > >>
> > >> Thanks,
> > >> Dave
> > >>
> > >> On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters <
> rawlin.pet...@gmail.com>
> > >> wrote:
> > >>
> > >>> Hey all,
> > >>>
> > >>> So it appears this vote passed in favor of adding a CHANGELOG.md file
> > >>> without having a changelog label in GitHub. Is anyone currently
> > >>> working on one?
> > >>>
> > >>> With the 2.2 release planned for 2/12/18, I'd like to at least put in
> > >>> some upgrade release notes about Per-Delivery-Service Routing Names.
> > >>> If no one has a CHANGELOG.md in progress, I'll take the liberty to
> > >>> start one and add those release notes in there (using
> > >>> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md as
> an
> > >>> example template).
> > >>>
> > >>> -Rawlin
> > >>>
> > >>> On Wed, Jan 10, 2018 at 10:35 AM, Chris Lemmons 
> > >>> wrote:
> > >>> > [X] +1 to adding a changelog.MD file
> > >>> > [] -1 to adding a changelog.MD file
> > >>> >
> > >>> > That said, I'm only in favour of it if we're fastidious about
> > >>> > requiring changelog updates on every single PR. A PR should either
> > >>> > provide a reasonable changelog entry, or, in the body of the PR,
> > >>> > justify it's absence. A simple "This bugfix does not require a
> > >>> > changelog entry." is sufficient for trivial bugfixes. That's plenty
> > >>> > for a reviewer to quickly either agree or decide to request (or
> > >>> > provide) an entry.
> > >>> >
> > >>> > If we add the changelog file, we need to update the contributing
> file
> > >>> > to include the new guidelines.
> > >>> >
> > >>> > On Wed, Jan 10, 2018 at 9:14 AM, Jeremy Mitchell <
> > mitchell...@gmail.com>
> > >>> wrote:
> > >>> >> Yes, I was about to mention milestones. Why not leverage Github
> > >>> milestones
> > >>> >> on issues/PRs? We talked about using milestones at the last TC
> > summit to
> > >>> >> determine the scope of a release. Now is our chance to do that.
> > >>> >>
> > >>> >> Milestones can be applied to issues or PRs. I tend to create
> issues
> > for
> > >>> >> everything I do, so I would put the milestone on the issue but
> > others
> > >>> can
> > >>> >> simply put a milestone on their PR (if there is no related issue).
> > >>> Either
> > >>> >> way, it tags the items we want included in the changelog. And then
> > the
> > >>> RM
> > >>> >> can build the changelog from the milestones. Easy peasy.
> > >>> >>
> > >>> >> Jeremy
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >>
> > >>> >> On Tue, Jan 9, 2018 at 4:56 PM, Leif 

Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

[Dan Kirkwood]

-1 because of an issue building traffic_ops from source:
https://github.com/apache/incubator-trafficcontrol/issues/1916

PR to fix this is forthcoming..


On Thu, Feb 22, 2018 at 6:15 AM, Steve Malenfant 
wrote:

> Maybe I should have mentioned a few more details...
>
> As for Traffic Ops/Portal, this upgrade was from earlier 2.2 build (early
> December).
> As for Monitor/Router/Stats, that was actually a 2.1 -> 2.2 upgrade.
>
> Steve
>
> On Wed, Feb 21, 2018 at 5:24 PM, Dave Neuman  wrote:
>
> > Hi Steve, for the upgrade did you go from 2.1 -> 2.2?
> >
> > On Wed, Feb 21, 2018 at 10:15 AM, Steve Malenfant 
> > wrote:
> >
> > > +1
> > >
> > > Upgraded the following succesfully to RC1:
> > > Traffic Ops
> > > Traffic Portal
> > > Traffic Monitor (from java to golang)
> > > Traffic Router
> > > Traffic Stats
> > >
> > > I only opened a single issue related with some required parameter for
> > > Traffic Monitor. But if used according to the default RASCAL profiles,
> no
> > > problem. Logs are specific. Issue is #1902.
> > >
> > > Steve
> > >
> > > On Wed, Feb 14, 2018 at 4:01 PM, Robert Butts  wrote:
> > >
> > > > Hello All,
> > > >
> > > > I've prepared a release for v2.2.0-RC1
> > > >
> > > > The vote is open for at least 72 hours and passes if a majority of at
> > > least
> > > > 3 +1 PPMC votes are cast.
> > > >
> > > > [ ] +1 Approve the release
> > > >
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > > Changes since 2.1.0:
> > > > https://github.com/apache/incubator-trafficcontrol/
> > > > compare/RELEASE-2.1.0...RELEASE-2.2.0-RC1
> > > >
> > > > This corresponds to git:
> > > >  Hash: ea549797d98c4fe96e484c9e88f82e2d7f876c1e
> > > >  Tag: RELEASE-2.2.0-RC1
> > > >
> > > > Which can be verified with the following: git tag -v
> RELEASE-2.2.0-RC1
> > > >
> > > > My code signing key is available here:
> > > > http://keys.gnupg.net/pks/lookup?search=0xFDD04F7F=vindex
> > > >
> > > > Make sure you refresh from a key server to get all relevant
> signatures.
> > > >
> > > > The source .tar.gz file, pgp signature (.asc signed with my key from
> > > > above), md5 and sha1 checksums are provided here:
> > > >
> > > > https://dist.apache.org/repos/dist/dev/incubator/
> > > trafficcontrol/2.2.0/RC1
> > > >
> > > >
> > > > Thanks!
> > > >
> > >
> >
>

Re: Golang Proxy Validation Dependencies

[Dan Kirkwood]

+1 -- agree with Jeff -- the validation of the fields of
deliveryservice is something that is incomplete in the Perl
traffic_ops.

These libraries make for concise code to do the validation so it will
be easier to extend without much extra code.   It will not be called
on every API function,  but only once on each POST/PUT which are a
small minority of calls.   It also need not be used in every case.
That, to me,  makes the reflection argument much less of a concern.

I would like to see it go in sooner than Friday,  but won't argue that point..

-dan


On Tue, Jan 16, 2018 at 10:10 AM, Dewayne Richardson  wrote:
> So, it's been a few days on this topic and I'd like to call a vote for the
> dependencies listed in this thread.  Please vote +1 or -1 by Noon Friday so
> that we can move forward the Golang Proxy development.
>
> Thanks,
>
> -Dew
>
> On Thu, Jan 11, 2018 at 10:53 AM, Jeff Elsloo  wrote:
>
>> I don't think we should assume anything about the performance just
>> because it uses reflection. Yes, traditionally reflection is
>> computationally expensive, however, when used properly the penalty can
>> be negligible. I don't think we have enough understanding of these
>> libraries to know whether there is a concerning performance penalty.
>>
>> As Dewayne said, create, update and delete actions represent a tiny
>> fraction of the overall requests into TO. Given that the majority of
>> these actions are performed by humans, I would be shocked if there was
>> a perceptible performance difference with the reflection based
>> validation in place. It's not like we're trying to validate enormous
>> and complex objects here; we're talking 20 fields or so for any given
>> post.
>>
>> I'm +1 on using validation libraries such as these even if they use
>> reflection, provided that we do not see dramatic changes in
>> performance. I think that's highly unlikely in this case.
>> --
>> Thanks,
>> Jeff
>>
>>
>> On Thu, Jan 11, 2018 at 10:07 AM, Chris Lemmons 
>> wrote:
>> > True, but how many of those out-of-the-box checks are both useful and
>> > relevantly complex?
>> >
>> > To me, the cool part of ozzo is the way it collects the output and
>> > formats it. That's unfortunately also the computationally expensive
>> > part.
>> >
>> > On Thu, Jan 11, 2018 at 9:49 AM, Dewayne Richardson 
>> wrote:
>> >> Please keep in mind that we do not Create/Update/Delete very often in
>> >> Traffic Ops, so the performance penalty for Validation should be taken
>> into
>> >> consideration.  I also don't want to re-invent all of those
>> out-of-the-box
>> >> field level checks by hand when I can just use them from here:
>> >> https://github.com/asaskevich/govalidator#list-of-functions
>> >>
>> >> -Dew
>> >>
>> >> On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons 
>> wrote:
>> >>
>> >>> I like the output style, but I'm a bit concerned on the performance
>> >>> front. ozzo appears to do all it's magic with heavy use of reflection,
>> >>> which is often a slow spot in go. Most places, it wouldn't matter
>> >>> much, but this will be called on every element of every API function,
>> >>> so a nod toward performance may be in order. Have we done some
>> >>> measurement to see whether this adds a relevant amount of overhead to
>> >>> the calls? Or are the calls still dominated by the DB lookup?
>> >>>
>> >>> Relatedly, is this a major advantage over something like this:
>> >>>
>> >>> if ds.Active == nil { errMsgs = append(errMsgs, `"active" must be
>> >>> provided`) }
>> >>>
>> >>> On Thu, Jan 11, 2018 at 8:49 AM, Dewayne Richardson <
>> dewr...@apache.org>
>> >>> wrote:
>> >>> > We've been moving along with more functionality in the Golang proxy,
>> >>> mostly
>> >>> > the Read's up until now, comparatively TO does much fewer
>> Create/Updates.
>> >>> > Our current task is to circle back and start implementing the
>> (C)reate,
>> >>> > (U)pdate, and (D)eletes.  One of the obvious needs for the this task
>> are
>> >>> > validation rules.  I've been doing research to figure out the
>> cleanest
>> >>> and
>> >>> > most maintainable way to rewrite the Perl validation rules in Go.
>> >>> >
>> >>> > TC Issue for tracking
>> >>> > https://github.com/apache/incubator-trafficcontrol/issues/1756
>> >>> >
>> >>> > These are the two dependencies I'd like to leverage and provide
>> feedback:
>> >>> >
>> >>> > Both are MIT Licenses
>> >>> > Uses normal programming constructs rather than error-prone struct
>> tags to
>> >>> > specify how data should be validated.
>> >>> > https://github.com/go-ozzo/ozzo-validation
>> >>> > https://github.com/go-ozzo/ozzo-validation/blob/master/LICENSE
>> >>> >
>> >>> > Core Validation library that the prior library uses that has a lot of
>> >>> > useful convenience methods that I'd rather not re-invent
>> >>> > https://github.com/asaskevich/govalidator
>> >>> > https://github.com/asaskevich/govalidator#list-of-functions
>> 

Re: [VOTE] CHANGELOG.md file (second try)

[Dan Kirkwood]

with the caveat that the name should be CHANGELOG.md or Changelog.md
to make it stand out in the directory listing and to use the standard
suffix.

[X] +1 to adding a changelog.MD file
[] -1 to adding a changelog.MD file
[] +1 to adding a changelog label in github
[X] -1 to adding a changelog label in github

On Tue, Jan 9, 2018 at 11:37 AM, Gelinas, Derek
 wrote:
> [X] +1 to adding a changelog.MD file
> [] -1 to adding a changelog.MD file
> [] +1 to adding a changelog label in github
> [X] -1 to adding a changelog label in github
>
> On 1/9/18, 1:28 PM, "Eric Friedrich (efriedri)"  wrote:
>
> [X] +1 to adding a changelog.MD file
> [] -1 to adding a changelog.MD file
>
> [] +1 to adding a changelog label in github
> [X] -1 to adding a changelog label in github
>
>
> I don’t think an auto-generated changelog will provide enough value to 
> our users. Asking for updates to changelog.md in each PR will make sure the 
> author carefully considers what users need to know, rather than just tossing 
> a label on the PR
>
> —Eric
>
> > On Jan 9, 2018, at 12:22 PM, Dave Neuman  wrote:
> >
> > Looks like this thread died over the holidays.  Let me try to bring it 
> back
> > up before we cut a 2.2 branch.
> > Can you please respond with *just* the following:
> >
> > [] +1 to adding a changelog.MD file
> > [] -1 to adding a changelog.MD file
> >
> > [] +1 to adding a changelog label in github
> > [] -1 to adding a changelog label in github
> >
> > Thanks,
> > Dave
> >
> > On Fri, Dec 15, 2017 at 9:14 AM, Dewayne Richardson 
> > wrote:
> >
> >> +1 on the CHANGELOG.md as well, but I like having the changelog label
> >> because it helps streamline it's creation.  I also think the labels are
> >> valuable because they help summarize the parts of the repo that 
> changed and
> >> keeps the concept closer to the repository (where the real change is).
> >>
> >> -Dew
> >>
> >> On Thu, Dec 14, 2017 at 3:01 PM, Robert Butts 
> 
> >> wrote:
> >>
> >>> +1. To clarify, I'm +1 on having the "changelog" label, to help 
> whoever
> >>> manually goes thru and builds the CHANGELOG.md.
> >>>
> >>> But I agree with @neuman I don't think we can automate this. Titles 
> are
> >> too
> >>> short, some changes need longer explanations and some don't, only a 
> human
> >>> can figure out how important something is to users; a high priority 
> bug
> >> fix
> >>> could still be low-impact, or vica-versa. Much as I dislike manual
> >> things,
> >>> this really needs human judgement. And we absolutely need a good
> >> Changelog
> >>> with each Release.
> >>>
> >>> On Thu, Dec 14, 2017 at 2:36 PM, Dave Neuman  
> wrote:
> >>>
>  Thanks for putting that together Dewayne. I was just starting to do
> >> that
>  myself when I saw it was already done.
>  As a developer this is fine, I can see a list of PRs and click on 
> each
> >>> one
>  to see the whole conversation.  I can comb through them and get a
> >> general
>  sense for what changed.
> 
>  However, as an operator and user of Traffic Control (which I mostly 
> am
>  these days) I am -1 for the following reasons:
>  1) only committers can assign labels to issues and pull requests.  
> This
>  means that the committers need to be cognizant of the issues/PRs they
> >> are
>  reviewing and apply the change log label;
>  2) the title of a PR only gives so much information about a change, 
> if
> >> I
>  want more information I have to click on each individual one
>  3) If I am not a developer, or someone who is very familiar with our
>  project, it is hard for me to ascertain from this list which changes
> >> are
>  super-important or have some operational considerations attached to
> >> them.
>  These are the issues I really care about.
>  4) When I go to do an upgrade, it's a lot easier to copy/paste a nice
>  bulleted list of what changed then it is to try to take a list of PRs
> >> and
>  turn it into a high level list of what's important.
> 
>  We need a solution that gives someone what they need at a glance.
> >>> Something
>  that can be copy/pasted out or easily linked to.  IMO not all of our
> >>> users
>  are super technical or involved in the day to day so we shouldn't 
> just
>  point them at a list of PRs and say "figure it out"; we should make 
> it
> >>> easy
>  for them to figure out.
> 
>  I have seen lots of alternatives suggested to what Steve has 
> proposed,
> >>> but
>  I 

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dan Kirkwood]

Hi Henk..I think those issues should now be resolved:
 - 1.8.x files removed from
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol
 - links to checksum and .asc signature files no longer point to the mirror

thanks for pointing these out!

Dan Kirkwood

On Thu, Dec 28, 2017 at 3:34 AM, Henk P. Penning <penn...@uu.nl> wrote:
> On Thu, 7 Dec 2017, Hank Beatty wrote:
>
>> Date: Thu, 7 Dec 2017 17:17:59 +0100
>> From: Hank Beatty <hbea...@apache.org>
>> To: gene...@incubator.apache.org
>> Cc: dev@trafficcontrol.incubator.apache.org
>> Subject: Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2
>
>
>> On 12/06/2017 04:14 AM, Henk P. Penning wrote:
>
>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.1.0/RC2/
>
>
>>> Please rename
>>>   apache-trafficcontrol-2.1.0-incubating.tar.gz.sha
>
>
>> I have renamed the file.
>
>
>   Some more points ; in dist/incubator/trafficcontrol/
>
>   PGP key c4b33c804587a8f0 [Dan Kirkwood <dang...@apache.org>] signed
>
> 1.8.0-incubating/trafficcontrol-incubating-1.8.0.tar.gz.asc
> 1.8.1-incubating/trafficcontrol-incubating-1.8.1.tar.gz.asc
>
>   ... but this key expired on 2017-11-08.
>
>   Please, either
>
> -- remove 1.8.0-incubating and 1.8.1-incubating
>from dist/incubator/trafficcontrol/
> -- fix (resign) key c4b33c804587a8f0 ;
> -- replace the .asc's
>
>   See https://checker.apache.org/projs/incubator.html
>   For help, see https://checker.apache.org/doc/README.html#prob-sigexp
>
>   Note that 1.8.0-incubating and 1.8.1-incubating must be
>   removed from dist/incubator/trafficcontrol/ when development
>   on those branches has stopped (replaced by 2.x).
>   [ http://www.apache.org/legal/release-policy.html#when-to-archive ]
>
>   Regarding your website :
>
> https://trafficcontrol.incubator.apache.org/downloads/index.html
>
>   Under "MD5 SHA512 PGP" you point to the mirrors, but sigs and
>   checksums aren't on the mirrors ; please refer to [note the https]
>
> https://www.apache.org/dist/incubator/trafficcontrol/
>
>   Please note that all your stuff in automatically archived at
>
> https://archive.apache.org/dist/incubator/trafficcontrol/
>
>   Thanks ; regard,
>
>   Henk Penning -- apache.org infrastructure ; mirrors
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dan Kirkwood]

My apologies -- Henk Penning -- not Hank...

On Thu, Dec 28, 2017 at 11:41 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote:
> +1 to removing the 1.8.0 and 1.8.1 releases per Hank's instructions...
>
> On Thu, Dec 28, 2017 at 11:22 AM, Dan Kirkwood <dang...@apache.org> wrote:
>
>> Hi all..I have updated the expiration date for my pgp key
>> c4b33c804587a8f0 in accordance with the instructions Hank Penning
>> included here.
>>
>> I also wanted to reach out regarding archiving old releases:   1.8.x
>> was our first release under the Apache Incubator -- that's the last
>> release using mysql.   We transitioned to using postgresql with 2.0.x,
>>   and have only done a single patch release for the 1.8.x series since
>> then.
>>
>> Unless there are objections,  I will remove the 1.8.0 and 1.8.1
>> releases per Hank's instructions.   I will leave the 2.0.x release in
>> place until we at least have an official 2.1.x release.
>>
>> If you concur,   please reply with a +1.
>>
>> thanks!  Dan
>>
>> On Thu, Dec 28, 2017 at 3:34 AM, Henk P. Penning <penn...@uu.nl> wrote:
>> > On Thu, 7 Dec 2017, Hank Beatty wrote:
>> >
>> >> Date: Thu, 7 Dec 2017 17:17:59 +0100
>> >> From: Hank Beatty <hbea...@apache.org>
>> >> To: gene...@incubator.apache.org
>> >> Cc: dev@trafficcontrol.incubator.apache.org
>> >> Subject: Re: [VOTE] Release Apache Traffic Control (incubating)
>> 2.1.0-RC2
>> >
>> >
>> >> On 12/06/2017 04:14 AM, Henk P. Penning wrote:
>> >
>> >
>> >>>>
>> >>>> https://dist.apache.org/repos/dist/dev/incubator/
>> trafficcontrol/2.1.0/RC2/
>> >
>> >
>> >>> Please rename
>> >>>   apache-trafficcontrol-2.1.0-incubating.tar.gz.sha
>> >
>> >
>> >> I have renamed the file.
>> >
>> >
>> >   Some more points ; in dist/incubator/trafficcontrol/
>> >
>> >   PGP key c4b33c804587a8f0 [Dan Kirkwood <dang...@apache.org>] signed
>> >
>> > 1.8.0-incubating/trafficcontrol-incubating-1.8.0.tar.gz.asc
>> > 1.8.1-incubating/trafficcontrol-incubating-1.8.1.tar.gz.asc
>> >
>> >   ... but this key expired on 2017-11-08.
>> >
>> >   Please, either
>> >
>> > -- remove 1.8.0-incubating and 1.8.1-incubating
>> >from dist/incubator/trafficcontrol/
>> > -- fix (resign) key c4b33c804587a8f0 ;
>> > -- replace the .asc's
>> >
>> >   See https://checker.apache.org/projs/incubator.html
>> >   For help, see https://checker.apache.org/doc/README.html#prob-sigexp
>> >
>> >   Note that 1.8.0-incubating and 1.8.1-incubating must be
>> >   removed from dist/incubator/trafficcontrol/ when development
>> >   on those branches has stopped (replaced by 2.x).
>> >   [ http://www.apache.org/legal/release-policy.html#when-to-archive ]
>> >
>> >   Regarding your website :
>> >
>> > https://trafficcontrol.incubator.apache.org/downloads/index.html
>> >
>> >   Under "MD5 SHA512 PGP" you point to the mirrors, but sigs and
>> >   checksums aren't on the mirrors ; please refer to [note the https]
>> >
>> > https://www.apache.org/dist/incubator/trafficcontrol/
>> >
>> >   Please note that all your stuff in automatically archived at
>> >
>> > https://archive.apache.org/dist/incubator/trafficcontrol/
>> >
>> >   Thanks ; regard,
>> >
>> >   Henk Penning -- apache.org infrastructure ; mirrors
>> >
>> >    _
>> > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
>> > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
>> > Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
>> > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
>>

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2

[Dan Kirkwood]

Hi all..I have updated the expiration date for my pgp key
c4b33c804587a8f0 in accordance with the instructions Hank Penning
included here.

I also wanted to reach out regarding archiving old releases:   1.8.x
was our first release under the Apache Incubator -- that's the last
release using mysql.   We transitioned to using postgresql with 2.0.x,
  and have only done a single patch release for the 1.8.x series since
then.

Unless there are objections,  I will remove the 1.8.0 and 1.8.1
releases per Hank's instructions.   I will leave the 2.0.x release in
place until we at least have an official 2.1.x release.

If you concur,   please reply with a +1.

thanks!  Dan

On Thu, Dec 28, 2017 at 3:34 AM, Henk P. Penning <penn...@uu.nl> wrote:
> On Thu, 7 Dec 2017, Hank Beatty wrote:
>
>> Date: Thu, 7 Dec 2017 17:17:59 +0100
>> From: Hank Beatty <hbea...@apache.org>
>> To: gene...@incubator.apache.org
>> Cc: dev@trafficcontrol.incubator.apache.org
>> Subject: Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC2
>
>
>> On 12/06/2017 04:14 AM, Henk P. Penning wrote:
>
>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.1.0/RC2/
>
>
>>> Please rename
>>>   apache-trafficcontrol-2.1.0-incubating.tar.gz.sha
>
>
>> I have renamed the file.
>
>
>   Some more points ; in dist/incubator/trafficcontrol/
>
>   PGP key c4b33c804587a8f0 [Dan Kirkwood <dang...@apache.org>] signed
>
> 1.8.0-incubating/trafficcontrol-incubating-1.8.0.tar.gz.asc
> 1.8.1-incubating/trafficcontrol-incubating-1.8.1.tar.gz.asc
>
>   ... but this key expired on 2017-11-08.
>
>   Please, either
>
> -- remove 1.8.0-incubating and 1.8.1-incubating
>from dist/incubator/trafficcontrol/
> -- fix (resign) key c4b33c804587a8f0 ;
> -- replace the .asc's
>
>   See https://checker.apache.org/projs/incubator.html
>   For help, see https://checker.apache.org/doc/README.html#prob-sigexp
>
>   Note that 1.8.0-incubating and 1.8.1-incubating must be
>   removed from dist/incubator/trafficcontrol/ when development
>   on those branches has stopped (replaced by 2.x).
>   [ http://www.apache.org/legal/release-policy.html#when-to-archive ]
>
>   Regarding your website :
>
> https://trafficcontrol.incubator.apache.org/downloads/index.html
>
>   Under "MD5 SHA512 PGP" you point to the mirrors, but sigs and
>   checksums aren't on the mirrors ; please refer to [note the https]
>
> https://www.apache.org/dist/incubator/trafficcontrol/
>
>   Please note that all your stuff in automatically archived at
>
> https://archive.apache.org/dist/incubator/trafficcontrol/
>
>   Thanks ; regard,
>
>   Henk Penning -- apache.org infrastructure ; mirrors
>
>    _
> Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC3

[Dan Kirkwood]

+1

On Thu, Dec 21, 2017 at 12:26 AM, Nir Sopher  wrote:
> +1
>
> On Thu, Dec 21, 2017 at 5:18 AM, Jeremy Mitchell 
> wrote:
>
>> +1
>>
>> On Wed, Dec 20, 2017 at 5:34 PM, Steve Malenfant 
>> wrote:
>>
>> > +1
>> >
>> > On Wed, Dec 20, 2017 at 5:14 PM, Dave Neuman  wrote:
>> >
>> > > +1
>> > >
>> > > On Wed, Dec 20, 2017 at 8:33 AM, Hank Beatty 
>> wrote:
>> > >
>> > > > Hello All,
>> > > >
>> > > > I've prepared a release for v2.1.0-RC3
>> > > >
>> > > > The vote is open for at least 72 hours and passes if a majority of at
>> > > > least 3 +1 PPMC votes are cast.
>> > > >
>> > > > [ ] +1 Approve the release
>> > > >
>> > > > [ ] -1 Do not release this package because ...
>> > > >
>> > > > Changes since 2.0.0:
>> > > > https://github.com/apache/incubator-trafficcontrol/compare/
>> > > > 2.0.x...RELEASE-2.1.0-RC3
>> > > >
>> > > > This corresponds to git:
>> > > >   Hash: 1dcd512f7e2b4898b090837cd3f260e453896e32
>> > > >   Tag: RELEASE-2.1.0-RC3
>> > > >
>> > > > Which can be verified with the following: git tag -v
>> RELEASE-2.1.0-RC3
>> > > >
>> > > > My code signing key is available here:
>> > > > https://pgp.mit.edu/pks/lookup?op=get=0x920152B94E0CC77C
>> > > >
>> > > > The source .tar.gz file, pgp signature (.asc signed with my key from
>> > > > above), md5 and sha512 checksums are provided here:
>> > > >
>> > > > https://dist.apache.org/repos/dist/dev/incubator/
>> > > trafficcontrol/2.1.0/RC3
>> > > >
>> > > > The new proposed download page can be found here:
>> > > >
>> > > > https://trafficcontrol.incubator.apache.org/downloads/index-new.html
>> > > >
>> > > > Thanks!
>> > > >
>> > >
>> >
>>

Re: Remove file with invalid license

[Dan Kirkwood]

```It is important to keep NOTICE as brief and simple as possible, as
each addition places a burden on downstream consumers.

Do not add anything to NOTICE which is not legally required.
```
https://www.apache.org/dev/licensing-howto.html#mod-notice
apache.org
Assembling LICENSE and NOTICE.
Home page of The Apache Software Foundation

On Tue, Dec 19, 2017 at 10:11 AM, Robert Butts <robert.o.bu...@gmail.com> wrote:
> I don't agree with
> https://github.com/apache/incubator-trafficcontrol/commit/d7422b3f05f2628de07614efa20799b01cfc1e41
> "remove from NOTICE to keep it short "
>
> While the MIT doesn't require Attribution, Daniel and the SecLists project
> originally did, it was very specifically licensed "CC Attribution", and
> they graciously changed for us.
>
> It seems rather rude not to include Attribution in accordance with their
> original wishes, even if we aren't legally required to.
>
> Is there a strong objection to keeping the NOTICE Attribution for them?
>
>
> On Tue, Dec 19, 2017 at 9:32 AM, Dave Neuman <neu...@apache.org> wrote:
>
>> I merged it, you need to do a backport to 2.1 as well.
>>
>> On Tue, Dec 19, 2017 at 9:16 AM, Robert Butts <robert.o.bu...@gmail.com>
>> wrote:
>>
>> > PR updating the license:
>> > https://github.com/apache/incubator-trafficcontrol/pull/1681
>> >
>> > On Tue, Dec 19, 2017 at 9:13 AM, Chris Lemmons <alfic...@gmail.com>
>> wrote:
>> >
>> > > https://github.com/danielmiessler/SecLists is now licensed MIT.
>> > > Thanks, Eric, for talking to Daniel Miessler for us and getting this
>> > > taken care of!
>> > >
>> > > On Mon, Dec 18, 2017 at 1:56 PM, Chris Lemmons <alfic...@gmail.com>
>> > wrote:
>> > > > Excellent, Eric. That neatly cleans up the problem. I do think we
>> > > > should merge my PR (1677), regardless, if for no other reason than to
>> > > > honour the authors' attribution request.
>> > > >
>> > > > On Mon, Dec 18, 2017 at 1:47 PM, Eric Friedrich (efriedri)
>> > > > <efrie...@cisco.com> wrote:
>> > > >> I emailed the owner of the password file earlier today and he agreed
>> > to
>> > > change or dual-license the project to MIT.
>> > > >>
>> > > >> —Eric
>> > > >>
>> > > >>> On Dec 18, 2017, at 3:40 PM, Phil Sorber <sor...@apache.org>
>> wrote:
>> > > >>>
>> > > >>> Rob,
>> > > >>>
>> > > >>> Just because we remove it for now doesn't mean we have to leave it
>> > out
>> > > >>> forever. I encourage you to contribute to the thread on the legal
>> > > mailing
>> > > >>> list to make your case or at least get an understanding of their
>> > > >>> requirements. The ASF does tend to lean toward conservative
>> > > interpretations.
>> > > >>>
>> > > >>> Thanks.
>> > > >>>
>> > > >>> On Mon, Dec 18, 2017 at 12:08 PM Robert Butts <
>> > > robert.o.bu...@gmail.com>
>> > > >>> wrote:
>> > > >>>
>> > > >>>> That's correct. No RPM, unfortunately. License is here:
>> > > >>>> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project.
>> > > >>>>
>> > > >>>> -1 on downloading during rpmbuild, or especially postinstall. Both
>> > > pose a
>> > > >>>> security risk. Moreover, it makes our build or install dependent
>> on
>> > > the
>> > > >>>> internet and a particular website. Neither building nor installing
>> > > should
>> > > >>>> require either internet or a particular website; we should be
>> > working
>> > > to
>> > > >>>> get away from that, not towards it.
>> > > >>>>
>> > > >>>> I'd prefer to find something Apache is ok with vendoring, if we
>> have
>> > > to.
>> > > >>>> Though, ideally we'd keep this one, Daniel Miessler is a
>> well-known
>> > > name in
>> > > >>>> the security community.
>> > > >>>>
>> > > >>>>
>> > > >>>> On Mon, Dec 18, 2017 at 11:51 AM, Dan Kirkwood <dang...@gmail.com
>>

Re: OWASP SecLists license

[Dan Kirkwood]

I do think,  however,  that we should have an actual download link so
the origin can be confirmed.

On Mon, Dec 18, 2017 at 1:18 PM, Dan Kirkwood <dang...@gmail.com> wrote:
> wow..   nicely done!
>
> On Mon, Dec 18, 2017 at 1:04 PM, Eric Friedrich (efriedri)
> <efrie...@cisco.com> wrote:
>>
>>
>> Begin forwarded message:
>>
>> From: Daniel Miessler 
>> <dan...@danielmiessler.com<mailto:dan...@danielmiessler.com>>
>> Subject: Re: OWASP SecLists license
>> Date: December 18, 2017 at 3:02:02 PM EST
>> To: Eric Friedrich <fri...@apache.org<mailto:fri...@apache.org>>
>>
>> Hi Eric,
>>
>> I think I’m going to change it to MIT.
>>
>> Go ahead and proceed as if it’s happened. I’ll make it so soon.
>>
>> Best,
>>
>> [X]
>>
>> On Dec 18, 2017, 10:45 -0800, Eric Friedrich 
>> <fri...@apache.org<mailto:fri...@apache.org>>, wrote:
>> Hi Daniel-
>>   I'm one of the committers on the Apache Traffic Control 
>> (https://trafficcontrol.apache.org/) project. We are currently using some of 
>> your common password list files as a dictionary checker and hoping to 
>> distribute this file as part of an upcoming release.
>>
>> During a license audit, we've been prevented from including any text under 
>> the CC-BY-SA 3/4 licenses.
>>
>> Would you be willing to re-license or dual-license that Github repo under a 
>> license more friendly to redistribution by Apache Software Foundation 
>> project?
>> This includes licenses such as: Apache, BSD, MIT and many others.
>>
>> The complete list is here: 
>> https://www.apache.org/legal/resolved.html#category-a
>>
>> Thank You!
>> Eric Friedrich
>> Apache Traffic Control (incubating) PPMC
>>

Re: OWASP SecLists license

[Dan Kirkwood]

wow..   nicely done!

On Mon, Dec 18, 2017 at 1:04 PM, Eric Friedrich (efriedri)
 wrote:
>
>
> Begin forwarded message:
>
> From: Daniel Miessler 
> >
> Subject: Re: OWASP SecLists license
> Date: December 18, 2017 at 3:02:02 PM EST
> To: Eric Friedrich >
>
> Hi Eric,
>
> I think I’m going to change it to MIT.
>
> Go ahead and proceed as if it’s happened. I’ll make it so soon.
>
> Best,
>
> [X]
>
> On Dec 18, 2017, 10:45 -0800, Eric Friedrich 
> >, wrote:
> Hi Daniel-
>   I'm one of the committers on the Apache Traffic Control 
> (https://trafficcontrol.apache.org/) project. We are currently using some of 
> your common password list files as a dictionary checker and hoping to 
> distribute this file as part of an upcoming release.
>
> During a license audit, we've been prevented from including any text under 
> the CC-BY-SA 3/4 licenses.
>
> Would you be willing to re-license or dual-license that Github repo under a 
> license more friendly to redistribution by Apache Software Foundation project?
> This includes licenses such as: Apache, BSD, MIT and many others.
>
> The complete list is here: 
> https://www.apache.org/legal/resolved.html#category-a
>
> Thank You!
> Eric Friedrich
> Apache Traffic Control (incubating) PPMC
>

Re: Remove file with invalid license

[Dan Kirkwood]

+1

On Mon, Dec 18, 2017 at 12:43 PM, Dave Neuman <neu...@apache.org> wrote:
> I personally don't want to see us hold up this release any longer,
> especially for something like this.  If folks really want to use this file,
> it's easy enough to have puppet put the file in place and use it in your
> own Traffic Control installation.  We can add documentation suggesting as
> much as well.  Rob, if you think you can find a suitable replacement in a
> decent timeframe then be my guest.  Otherwise, I think we should replace
> the file with a blank file (or create our own version) and move on.
> If legal comes back and decides the file is ok, we can re-introduce it in
> the 2.2 release.
>
> --Dave
>
> On Mon, Dec 18, 2017 at 12:08 PM, Robert Butts <robert.o.bu...@gmail.com>
> wrote:
>
>> That's correct. No RPM, unfortunately. License is here:
>> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project.
>>
>> -1 on downloading during rpmbuild, or especially postinstall. Both pose a
>> security risk. Moreover, it makes our build or install dependent on the
>> internet and a particular website. Neither building nor installing should
>> require either internet or a particular website; we should be working to
>> get away from that, not towards it.
>>
>> I'd prefer to find something Apache is ok with vendoring, if we have to.
>> Though, ideally we'd keep this one, Daniel Miessler is a well-known name in
>> the security community.
>>
>>
>> On Mon, Dec 18, 2017 at 11:51 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>>
>> > Thanks,  Eric..Then it's possible we could download it during
>> > rpmbuild or postinstall.
>> >
>> > On Mon, Dec 18, 2017 at 11:40 AM, Eric Friedrich (efriedri)
>> > <efrie...@cisco.com> wrote:
>> > > It can be downloaded from Github.
>> > >
>> > > I think this is the file (Rob correct me if I picked the wrong
>> variant):
>> > https://github.com/danielmiessler/SecLists/blob/
>> > master/Passwords/10_million_password_list_top_10.txt
>> > >
>> > > —Eric
>> > >
>> > > On Dec 18, 2017, at 1:38 PM, Dan Kirkwood <dang...@gmail.com> dang
>> > o...@gmail.com>> wrote:
>> > >
>> > > Rob,   is there a specific download location for this file?   I see it
>> > > referenced as "Projects/OWASP SecLists Project",  but didn't find it
>> > > with a quick search.   Is it possible it's provided by an rpm we could
>> > > list as a dependency rather than including in our source?
>> > >
>> > > -dan
>> > >
>> > > On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts <
>> robert.o.bu...@gmail.com
>> > <mailto:robert.o.bu...@gmail.com>> wrote:
>> > > I'd really like to keep this, or replace it with a similar file from
>> > > another source. Which I'd be willing to investigate, if necessary.
>> > >
>> > > Having a good blacklist of most-common passwords specifically puts
>> > Traffic
>> > > Ops in compliance with NIST SP 800-63B.
>> > >
>> > > I also don't understand the objections, the Apache Legal FAQ
>> specifically
>> > > says CC-SA is permissible, and doesn't say anything about being limited
>> > to
>> > > binary (which would be odd, CC is designed for text, not binary).
>> > > https://www.apache.org/legal/resolved.html#cc-sa
>> > >
>> > > I'd vote we wait for the legal resolution, or find a suitable
>> > replacement,
>> > > in order to remain in NIST compliance.
>> > >
>> > >
>> > > On Mon, Dec 18, 2017 at 10:55 AM, David Neuman <
>> david.neuma...@gmail.com
>> > >
>> > > wrote:
>> > >
>> > > Hey all,
>> > > I don't know if you have been following the release 2.1 thread on the
>> > > incubator list [1] , but we have been given a -1 vote by the IPMC for
>> > > having a file in our release [2] that has an incompatible license.
>> There
>> > > is some debate about the license, and we have reached out to Legal for
>> > more
>> > > information [3] (thanks Eric!), but we haven't heard back from legal
>> yet.
>> > > Instead of waiting for legal to get back to us, I would like to propose
>> > > that we instead remove this file from our release.  The file in
>> question
>> > is
>> > > just a list of weak passwords and I feel like we

Re: Remove file with invalid license

[Dan Kirkwood]

Thanks,  Eric..Then it's possible we could download it during
rpmbuild or postinstall.

On Mon, Dec 18, 2017 at 11:40 AM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> It can be downloaded from Github.
>
> I think this is the file (Rob correct me if I picked the wrong variant): 
> https://github.com/danielmiessler/SecLists/blob/master/Passwords/10_million_password_list_top_10.txt
>
> —Eric
>
> On Dec 18, 2017, at 1:38 PM, Dan Kirkwood 
> <dang...@gmail.com<mailto:dang...@gmail.com>> wrote:
>
> Rob,   is there a specific download location for this file?   I see it
> referenced as "Projects/OWASP SecLists Project",  but didn't find it
> with a quick search.   Is it possible it's provided by an rpm we could
> list as a dependency rather than including in our source?
>
> -dan
>
> On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts 
> <robert.o.bu...@gmail.com<mailto:robert.o.bu...@gmail.com>> wrote:
> I'd really like to keep this, or replace it with a similar file from
> another source. Which I'd be willing to investigate, if necessary.
>
> Having a good blacklist of most-common passwords specifically puts Traffic
> Ops in compliance with NIST SP 800-63B.
>
> I also don't understand the objections, the Apache Legal FAQ specifically
> says CC-SA is permissible, and doesn't say anything about being limited to
> binary (which would be odd, CC is designed for text, not binary).
> https://www.apache.org/legal/resolved.html#cc-sa
>
> I'd vote we wait for the legal resolution, or find a suitable replacement,
> in order to remain in NIST compliance.
>
>
> On Mon, Dec 18, 2017 at 10:55 AM, David Neuman <david.neuma...@gmail.com>
> wrote:
>
> Hey all,
> I don't know if you have been following the release 2.1 thread on the
> incubator list [1] , but we have been given a -1 vote by the IPMC for
> having a file in our release [2] that has an incompatible license.  There
> is some debate about the license, and we have reached out to Legal for more
> information [3] (thanks Eric!), but we haven't heard back from legal yet.
> Instead of waiting for legal to get back to us, I would like to propose
> that we instead remove this file from our release.  The file in question is
> just a list of weak passwords and I feel like we can easily include a blank
> file, or a file with a couple passwords that we generate, and individual
> installs of Traffic Control can replace this file as they see fit.  This
> will
> remove issue of having an incompatible license in our release and should
> also not require us to do a code change.  The downside of removing this
> file is that we will need to create another 2.1 release candidate and go
> through the vote process again.  I would really like to see us get 2.1
> released before the end of the year, and at this point our chances are
> looking pretty slim.  So, does anyone object to removing this file from our
> release?  If not, I will put an issue into github, remove the file, and
> back port the change so that we can get another 2.1 release candidate out.
>
> Thanks,
> Dave
>
>
> [1]
> https://lists.apache.org/thread.html/c211f049e3d68af90196c30f6b6d31
> a67b3072029dea1efe7d35c9dc@%3Cdev.trafficcontrol.apache.org%3E
> [2]
> apache-trafficcontrol-2.1.0-incubating/traffic_ops/app/
> conf/invalid_passwords.txt
> [3] https://issues.apache.org/jira/browse/LEGAL-356
>
>

Re: [VOTE] CHANGELOG.md file (second try)

[Dan Kirkwood]

+1 as well...

This query should show all PRs merged since the 2.1 branch:

https://github.com/apache/incubator-trafficcontrol/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed+merged%3A%3E%3D2017-08-04+base%3Amaster

On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell  wrote:
> This label idea would require everyone to go back and find their PRs that
> were closed after Aug 4th (the date 2.1 branch was created) and attach the
> 'change log' label and the 2.2 milestone to the appropriate ones, right?
> And then that link dew provide would be an accurate picture of what has
> changed between 21. and 2.2...
>
> of course, ignore PRs that don't affect the "interface" like "license
> changes", right?
>
> i like the idea...
>
> On Thu, Dec 14, 2017 at 1:59 PM, Dewayne Richardson 
> wrote:
>
>> As a POC for the Change Log label follow this link:
>>
>> https://github.com/apache/incubator-trafficcontrol/
>> pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+milestone%3A2.2.0
>>
>> -Dew
>>
>> On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek <
>> derek_geli...@comcast.com>
>> wrote:
>>
>> > I'm +1 for the label as well.
>> >
>> > > On Dec 14, 2017, at 12:29 PM, Robert Butts 
>> > wrote:
>> > >
>> > > +1 on a "changelog" label. Seems like that would make it a lot easier
>> for
>> > > the person writing it up. Easier to skip things like code maintenance
>> > that
>> > > have no interface effect.
>> > >
>> > > On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson <
>> dewr...@gmail.com>
>> > > wrote:
>> > >
>> > >> Another idea would be to include a new CHANGELOG label that you could
>> > tack
>> > >> onto specific PR's that you wanted to be included (as well as grouped
>> > >> within Milestones) as the high level features that went into the
>> > release.
>> > >> As for the gotchas, I think those should be Github issues because to
>> me
>> > >> those were bugs.
>> > >>
>> > >> -Dew
>> > >>
>> > >> On Thu, Dec 14, 2017 at 10:01 AM, Jeremy Mitchell <
>> > mitchell...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> I agree. Very readable. I also like the idea of a either creating a
>> > >>> CHANGELOG.md for each component...or one CHANGELOG.md with sections
>> for
>> > >>> each component.
>> > >>>
>> > >>> I still do like the idea of creating issues with milestones but I'll
>> > let
>> > >>> that go. That seems to be a personal preference of mine.
>> > >>>
>> > >>> Jeremy
>> > >>>
>> >  On Thu, Dec 14, 2017 at 9:45 AM, Dave Neuman 
>> > wrote:
>> > 
>> >  Have you taken a look at some Changelogs of other github projects?
>> > >> Here
>> >  are a few from other projects we use in Traffic Control:
>> >  - Docker Compose: https://github.com/docker/
>> > >>> compose/blob/master/CHANGELOG.
>> >  md
>> >  - InfluxDB: https://github.com/influxdata/influxdb/blob/master/
>> >  CHANGELOG.md
>> >  - Grafana: https://github.com/grafana/grafana/blob/master/CHANGELOG
>> .
>> > md
>> >  - Ansible: https://github.com/ansible/ansible/blob/devel/CHANGELOG.
>> md
>> > 
>> >  See how easy to read those are and how they provide a lot of
>> > >> information
>> >  without having to wade through hundreds of issues and pull requests?
>> > >>> Some
>> >  of them also have links to issues for new features, as well as bug
>> > >> fixes
>> >  that are in the current release.  I think all of them are easy to
>> read
>> > >>> and
>> >  can give a user a quick overview of what is in the new release. I
>> > think
>> >  it's fine to add a link to all the issues if we want, but I think
>> >  ultimately we want to create something like what I have linked to
>> > >> above.
>> >  We might also want to break out our CHANGELOG.md by component to
>> > >> provide
>> >  even more readability.
>> > 
>> >  I know our first inclination is to try to automate everything, but
>> >  sometimes it makes sense to do things manually so that you can
>> create
>> > a
>> >  better output.
>> > 
>> > 
>> > 
>> >  On Thu, Dec 14, 2017 at 8:55 AM, Jeremy Mitchell <
>> > >> mitchell...@gmail.com>
>> >  wrote:
>> > 
>> > > What if CHANGLOG.md includes 2 things:
>> > >
>> > > 1. a link to 2.2 issues (i.e.
>> > > https://github.com/apache/incubator-trafficcontrol/
>> > > issues?q=is%3Aopen+is%3Aissue+milestone%3A2.2.0
>> > > 2. a bulleted list of 2.2 gotchas (i.e. Traffic Ops Golang doesn't
>> >  connect
>> > > to a Riak with self-signed certificates; Riak security grant needs
>> >  updated;
>> > > upgrade param needed for ds routing names, etc, etc...)
>> > >
>> > > But again this requires everyone to create issues (with a
>> milestone)
>> > >> in
>> > > which one or more PR's can be attached to.
>> > >
>> > > Dave, you said "If you are developing a new feature you could
>> easily
>> > >>> end
>> >  up
>> > > with 5 or more PRs"

Re: Build failed in Jenkins: incubator-trafficcontrol-PR #732

[Dan Kirkwood]

FYI -- apparently the Fedora project is doing some infrastructure
maintenance which is causing the builds to fail...  Hopefully will be
resolved before long..

https://status.fedoraproject.org/

-dan

On Tue, Dec 5, 2017 at 1:22 PM, Apache Jenkins Server
 wrote:
> See 
> 
>
> Changes:
>
> [robert.o.butts] Fix Dockerfile for Traffic Ops
>
> [robert.o.butts] Change TO Dockerfile RPM to omit version, URI
>
> [robert.o.butts] Remove TO postinstall unnecessary ->
>
> [robert.o.butts] Remove Dockerfile TO mysql comment
>
> --
> [...truncated 15.47 KB...]
>  perl-Exporter noarch5.68-3.el7base28 
> k
>  perl-File-Pathnoarch2.09-2.el7base26 
> k
>  perl-File-Tempnoarch0.23.01-3.el7 base56 
> k
>  perl-Filter   x86_641.49-3.el7base76 
> k
>  perl-Getopt-Long  noarch2.40-2.el7base56 
> k
>  perl-Git  noarch1.8.3.1-12.el7_4  updates 53 
> k
>  perl-HTTP-Tinynoarch0.033-3.el7   base38 
> k
>  perl-PathToolsx86_643.40-5.el7base82 
> k
>  perl-Pod-Escapes  noarch1:1.04-292.el7base51 
> k
>  perl-Pod-Perldoc  noarch3.20-4.el7base87 
> k
>  perl-Pod-Simple   noarch1:3.28-4.el7  base   216 
> k
>  perl-Pod-Usagenoarch1.63-3.el7base27 
> k
>  perl-Scalar-List-Utilsx86_641.27-248.el7  base36 
> k
>  perl-Socket   x86_642.010-4.el7   base49 
> k
>  perl-Storable x86_642.45-3.el7base77 
> k
>  perl-TermReadKey  x86_642.30-20.el7   base31 
> k
>  perl-Text-ParseWords  noarch3.29-4.el7base14 
> k
>  perl-Thread-Queue noarch3.02-2.el7base17 
> k
>  perl-Time-HiRes   x86_644:1.9725-3.el7base45 
> k
>  perl-Time-Local   noarch1.2300-2.el7  base24 
> k
>  perl-constant noarch1.27-2.el7base19 
> k
>  perl-libs x86_644:5.16.3-292.el7  base   688 
> k
>  perl-macros   x86_644:5.16.3-292.el7  base43 
> k
>  perl-parent   noarch1:0.225-244.el7   base12 
> k
>  perl-podlatorsnoarch2.5.1-3.el7   base   112 
> k
>  perl-srpm-macros  noarch1-8.el7   base   4.6 
> k
>  perl-threads  x86_641.87-4.el7base49 
> k
>  perl-threads-shared   x86_641.43-6.el7base39 
> k
>  redhat-rpm-config noarch9.1.0-76.el7.centos   base79 
> k
>  rsync x86_643.0.9-18.el7  base   360 
> k
>  unzip x86_646.0-16.el7base   169 
> k
>  zip   x86_643.0-11.el7base   260 
> k
>
> Transaction Summary
> 
> Install  3 Packages (+50 Dependent packages)
>
> Total download size: 22 M
> Installed size: 78 M
> Downloading packages:
> warning: /var/cache/yum/x86_64/7/base/packages/bzip2-1.0.6-13.el7.x86_64.rpm: 
> Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY
> Public key for bzip2-1.0.6-13.el7.x86_64.rpm is not installed
> Public key for epel-release-7-9.noarch.rpm is not installed
> Public key for git-1.8.3.1-12.el7_4.x86_64.rpm is not installed
> 
> Total  5.9 MB/s |  22 MB  00:03
> Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
> Importing GPG key 0xF4A80EB5:
>  Userid : "CentOS-7 Key (CentOS 7 Official Signing Key) 
> "
>  Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
>  Package: centos-release-7-4.1708.el7.centos.x86_64 (@CentOS)
>  From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
>   Installing : fipscheck-1.4.1-6.el7.x86_64
> 1/53
>   Installing : fipscheck-lib-1.4.1-6.el7.x86_64
> 2/53
>   Installing : groff-base-1.22.2-8.el7.x86_64  
> 3/53
>   Installing : 1:perl-parent-0.225-244.el7.noarch  
> 4/53
>   Installing : 

change to cdn.conf

[Dan Kirkwood]

Hi, all..

With our ongoing effort to move Traffic Ops from the Perl Mojolicious
framework to Go,   one thing that's hampered this effort is
duplication of configuration.   The cdn.conf has always been in Perl
hash form.

To prevent the need to parse Perl constructs in Go,  I've introduced a
change that reads it instead in JSON,  which can easily be read by
both Go and Perl:
https://github.com/apache/incubator-trafficcontrol/pull/1350

The change is actually fairly simple and does not change the Perl side
at all,  but all configuration is now together.   I still kept the
database configuration separate.

This change will go in to Traffic Ops 2.2.   The release notes will
describe the change and how to change the configuration when
upgrading.

Any comments or suggestions to this change are welcome..

-dan

Re: Traffic Ops Rewrite Golang Dependency - sqlx

[Dan Kirkwood]

As one ready to jump in and add more endpoints,  I'm a strong +1 on
using sqlx.  I agree that adding a new dependency should not be done
without consideration,  but I find the sqlx version much more readable
and easier to approach than either your or dew's version of non-sqlx
and would be much easier to approach for one unfamiliar with details
of this project.   For me,   it's worth it.

strong +1

-dan


On Tue, Sep 12, 2017 at 7:52 PM, Robert Butts  wrote:
> I am a pretty big -1 on sqlx. Those PRs are extremely deceptive.
>
> Those lines are entirely unnecessary.
>
> I have created an example PR at https://github.com/apache/incu
> bator-trafficcontrol/pull/1165
>
> The relevant commits are
> https://github.com/apache/incubator-trafficcontrol/pull/1165
> /commits/6fc735d7f97eaaffbf08e8457b7ccb6bf14baca0
> https://github.com/apache/incubator-trafficcontrol/pull/1165
> /commits/6939ee1d401c571af139db53b018a5e53f80c02a#diff-219ca
> ea1a282285fe1cc21e53bf9dafbL26
>
> As you can see, the only difference is that `rows.StructScan()` becomes `
> rows.Scan(, , , , 
> DomainName, , , , , , 
> IloIpGateway, , , , 
> InterfaceMtu, , , , ,
> , , , , 
> MgmtIpGateway, , , , 
> PhysLocationId, , , , , 
> RevalPending, , , , ,
> , , , , , 
> XmppPasswd)`
>
> It is a one-line difference per endpoint, not 100 lines. (Plus column
> annotations on every struct field for sqlx)
>
> That said, I agree the former is better for readability. The issue is the
> maintenance cost, when-not-if sqlx stops being maintained. It will be
> embedded in Traffic Ops, in every single endpoint and query. We'll be in
> exactly the same position we are with Goose, stuck with an unmaintained and
> probably vulnerable library, which is very expensive in developer-hours to
> remove. Surely most of us here have been in this situation, with legacy
> unmaintained apps, libraries, compilers, etc?
>
> By `cloc` Sqlx is 3400 lines, which doesn't sound like a lot, but a big
> percentage of that is Go Reflection, which is exceedingly painful to write,
> debug, and maintain.
>
> Is standard Go really that much more difficult to write? The above is one
> of the worst cases (along with Deliveryservices), most of our tables aren't
> nearly that big. It doesn't seem likely to cause bugs, any mismatches
> should be immediately caught when running the first time, and certainly by
> the tests we've been mandating.
>
> I'm not wholesale against third-party libraries. Often the benefit
> outweighs the cost; for example, `sqlmock`, and in the future, `jwt`. But
> in this particular case, the maintenance cost far outweighs the benefit.
>
> This isn't a black-and-white issue, it's a cost-benefit analysis. Sqlx is
> marginally easier to write, for an unknowable and potentially enormous
> future cost.
>
>
> On Tue, Sep 12, 2017 at 6:54 PM, Volz, Dylan (Contractor) <
> dylan_v...@comcast.com> wrote:
>
>> It would be maintaining about a 1500 line codebase (excluding tests with
>> ~70% coverage), it uses reflection and tag introspection so it isn’t the
>> simplest go code but it does seem to be well commented.
>>
>> On 9/12/17, 6:36 PM, "Gelinas, Derek"  wrote:
>>
>> After looking at the code, and given the work I've been doing with
>> rewriting the config file endpoints, I have to say sqlx all the way.
>> What's involved in the maintenance?
>>
>> Derek
>>
>> On Sep 12, 2017, at 8:28 PM, Dewayne Richardson > > wrote:
>>
>> There has been quite a bit of discussion about how to move forward
>> with the
>> Traffic Ops Rewrite in terms of Golang dependencies.  Currently there
>> is
>> only one dependency for Mocking out the database for unit testing
>> called
>> https://github.com/DATA-DOG/go-sqlmock. Another that we want to
>> evaluate is
>> https://github.com/jmoiron/sqlx for accessing Postgres to help with
>> minimizing Golang boilerplate code.  The following are the Pros and
>> Cons
>> are listed to he
>> lp decide (please add any that I failed to include)
>>
>>
>> Pros
>> - Developer productivity increases (less boilerplate code)
>> - Less Developer errors through tedious field mapping
>> - Active Development
>>
>> Cons
>> - Another dependency to maintain if it is no longer supported
>>
>> Performance
>>  The performance penalty is neglible (I tested the /api/1.2/servers
>> endpoint, very loosely, in the Comcast Open Stack lab using the
>>  same VM and Apache Bench with 1000, 1, and 1 separate requests
>> and the performance was +/-5% depending on the cloud resources that
>> were
>> active).
>>  Remember, this endpoint is still 20x faster than the Traffic Ops Perl
>> version.
>>
>>
>> So, please review the following PR's specifically noting the
>> servers.go and
>> servers_test.go files (also browser around to see our progress)
>>
>> WITH Sqlx
>> 

traffic_ops postinstall/rpm update changes

[Dan Kirkwood]

Hi all..

With Traffic Ops 2.2,   we will be adding a couple of keys to the
cdn.conf.   Our initial thought was to add that change to postinstall,
 but that process has become unwieldy and difficult to maintain.

What we propose to do instead is update the cdn.conf in the release
with these changes -- any existing installation will not replace the
existing cdn.conf,  but create a cdn.conf.rpmnew.

It will be up to the administrator of the installation to make the
appropriate changes to the cdn.conf based on the contents of that
rpmnew file.   This will be true for other config file changes in the
future as well.

At most installations,  the handling of those config files is likely
to be handled by a configuration management system like puppet or
ansible.   The recommendation would be to update the file using that
mechanism so it is consistently applied.

With that in mind,  I'm planning on simplifying postinstall by
removing any "update" features.   It would be used only for initial
installs.   If the rpm is an update to an existing install,  the "run
postinstall" message would not be produced.

Does anyone have concerns with this plan?   I should have a PR for
review later this week.

thanks..  Dan Kirkwood

Re: [VOTE] Bugtracking in Github Issues

[Dan Kirkwood]

+1

On Mon, Aug 28, 2017 at 10:38 AM, Eric Friedrich (efriedri)
 wrote:
> We currently use JIRA Issues to track all of the Traffic Control bugs.
>
> Now that we have write access to Github, we can move back to GH Issues for 
> bug tracking.
>
> This will be a better workflow because its one fewer tool and account to have 
> to interact with. This will hopefully lower the bar for new contributors to 
> file bugs and engage with the product. We can also help use it (along with 
> the milestones) to create more useful changelogs and release notes.
>
> A possible downside is that the Issues are maybe less flexible than JIRA in 
> terms of permissions, workflow, fields, etc. However, we were using Issues 
> before we entered the incubator and that was fine for us. Hopefully no one 
> has developed an attachment for JIRA in the last year.
>
>
> Please Vote +1 to move to Github Issues or -1 to stay on Jira. I’ll assume a 
> lazy consensus if there aren’t enough votes.
>
> —Eric
>
>

Re: Pull Request Builder on Apache Jenkins

[Dan Kirkwood]

the former indicates any commits to this PR will cause a new build to
happen.  The latter is one time only.

On Tue, Aug 8, 2017 at 3:48 PM, Phil Sorber <sor...@apache.org> wrote:
>> "ok to test" to accept this pull request for testing
>> "test this please" for a one time test run
>
> What is the difference between these two?
>
> On Tue, Aug 8, 2017 at 3:46 PM Volz, Dylan (Contractor) <
> dylan_v...@comcast.com> wrote:
>
>> Perhaps it could check for WIP prefix to prevent noisy(?) failures on
>> incomplete work?
>>
>> On 8/8/17, 3:39 PM, "Dan Kirkwood" <dang...@apache.org> wrote:
>>
>> Hi all...   We have projects in the Apache Jenkins server under this
>> folder: https://builds.apache.org/view/S-Z/view/TrafficControl/
>>
>> I've added a new project there to build new PR:
>>
>> https://builds.apache.org/view/S-Z/view/TrafficControl/job/incubator-trafficcontrol-PR/
>>
>> Details below,   and also documented in the description at the top of
>> that page.
>>
>> Questions/Concerns?   Please follow up to the dev mailing list here.
>>
>> -dan
>>
>> -
>> When a new pull request is opened in the project, it will build
>> automatically if the author is already whitelisted.
>>
>> If the author is not white-listed, builder will ask (in PR comments)
>> "Can one of the admins verify this patch?". Any committer can respond
>> in the PR comments:
>>
>> "ok to test" to accept this pull request for testing
>> "test this please" for a one time test run
>> "add to whitelist" to add the author to the whitelist
>>
>> If the build fails for other various reasons you can rebuild:
>>
>> "retest this please" to start a new build
>>
>>
>>
>>

Re: Pull Request Builder on Apache Jenkins

[Dan Kirkwood]

looks like it will skip if the title contains [skipXXXci] where XXX is
any non-whitespace..  Not sure why that form,  but it's possible.

I'll wait for other feedback before making any change to that.

Re: Proposal for PR requirements

[Dan Kirkwood]

Thanks,   Jason..I'll look into that.

+1 on Dave's comments -- the process shouldn't be that heavy-weight.
Yes -- there *should* be Jira tickets for anything not trivial,  but
should be at the discretion of the PR reviewer whether to request it
or not..

-dan

On Wed, Jul 19, 2017 at 7:55 AM, Jason Tucker  wrote:
> Re: the github PR trigger thing
>
> It looks like those hooks are available:
> https://blogs.apache.org/infra/entry/github_pull_request_builds_now
>
> Here's an example of it being used by the kafka project:
>
> https://github.com/apache/kafka/pull/3546
>
> Once those status checks are being returned, then the status gates can be
> turned on under branch protection.
>
> __Jason
>
> On Tue, Jul 18, 2017 at 10:33 PM, Dave Neuman  wrote:
>
>> I personally don't think that we should require a Jira for every single
>> PR.  I think blanket statements like "you must create a Jira ticket for
>> each PR", while made with good intentions, are too hard to enforce, don't
>> take every situation into account, and are sometimes a deterrent to new
>> contributors.  If Joe somebody from the internet wants to submit a PR, we
>> should welcome it and not say "we are not accepting this without first
>> creating a Jira account and then creating a Jira ticket".
>>
>> The changelog thing is a real problem.  We had a plan to have an
>> auto-generated changelog, but that was reliant on us moving to full github
>> which we haven't done yet.  I think maybe the changelog conversation might
>> need to be re-visited.
>>
>> Have you taken a look at our contributing guide[1] on github?  It already
>> outlines a lot of the things you are proposing here and I think its the
>> best place to have our PR requirements.
>>
>> I like Jason's idea, though not sure if it is possible.
>>
>> [1]
>> https://github.com/apache/incubator-trafficcontrol/blob/
>> master/CONTRIBUTING.md
>>
>> Thanks,
>> Dave
>>
>> On Tue, Jul 18, 2017 at 8:08 PM, Jason Tucker 
>> wrote:
>>
>> > Do you know if the the apache jenkins instance supports PR-triggered
>> > builds? If so, then repo branches can be protected so that PRs can only
>> be
>> > merged if the build status is successful. Might be a good safeguard to
>> have
>> > in place, if we have the ability to enable it on the jenkins side.
>> >
>> > __Jason
>> >
>> > On Wed, Jul 19, 2017 at 12:19 AM, Gelinas, Derek <
>> > derek_geli...@comcast.com>
>> > wrote:
>> >
>> > > As the project grows in complexity and the speed of updates, we're
>> > finding
>> > > a real need for changelogs and a reduction in the number of commits.
>> At
>> > > this time, creating a changelog over even a short period of time is a
>> > > tedious and time consuming activity, and it is making even incremental
>> > > updates difficult for us here at Comcast.
>> > >
>> > > I would like to propose the following:
>> > >
>> > >
>> > >   *   Each PR must have a linked jira issue.  This is as simple as
>> > > creating the ticket and then adding [TC-XXX] to the beginning of the PR
>> > > title.  The jira ticket title should briefly describe the fix or new
>> > > feature in a manner which lends itself to inclusion in a changelog.
>> > >   *   Large changes should have as much information as possible about
>> the
>> > > nature of the change and how this change affects the system.
>> > >   *   Testing should be done on all changes before the PR is submitted!
>> > > Please do not submit anything that has not been fully tested,
>> regardless
>> > of
>> > > how simple or obvious it may seem.  You are the first line of defense
>> > > against bugs!  If the work is not yet complete, be sure to add [WIP] to
>> > the
>> > > title of the PR.
>> > >   *   Commits should be squashed as much as possible before the PR is
>> > > submitted.  27 commits for minor changes make review and later analysis
>> > > very difficult.  Commit messages should be descriptive so it is clear
>> > what
>> > > was changed.
>> > >   *   New features or changes to functionality should include
>> > > documentation changes whenever possible.
>> > >   *   Integration testing should be included whenever possible - we now
>> > > have automated integration testing, so this is another valuable method
>> to
>> > > isolate bugs before they hit the field.
>> > >   *   When in doubt, be clear about what you are doing!
>> > >
>> > > I would also like to propose that if these requirements are not met
>> > > without specific reasoning, PRs should be rejected until they are
>> > corrected.
>> > >
>> > > Derek
>> > >
>> >
>>

Re: 2.1 RM

[Dan Kirkwood]

Thanks,  Hank..feel free to ping either me or Eric if anything is
unclear in the release manager notes.

-dan

On Mon, Jul 17, 2017 at 12:56 PM, Hank Beatty  wrote:
> Hi Dave,
>
> I would like to volunteer.
>
> Thanks,
> Hank
>
> On 07/05/2017 03:38 PM, Dave Neuman wrote:
>>
>> Hey All,
>> Now that 2.0 has officially passed the project and IPMC vote (YAY!), it's
>> time to start thinking about 2.1.  I don't think we have identified a
>> release manager for the 2.1 release yet, would anyone like to volunteer?
>>
>> Thanks,
>> Dave
>>
>

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC6)

[Dan Kirkwood]

+1

I checked:
- git tag verified
- gpg sig is good
- checksums match source tarball
- tarball has correct name and structure
- rpms build from tarball
- traffic_ops installation and postinstall on a clean Centos7 VM
- some basic traffic_ops UI functionality
- docs no longer mention build area to download rpms

One caveat -- gpg signature is not signed and so not in the web of
trust,  but according to
http://www.apache.org/dev/release-distribution.html#sigs-and-sums :

"Signing keys SHOULD be linked into a strong web of trust."

We should get Eric's key signed at the earliest opportunity,  but it's
not a requirement for the release.

On Fri, Jun 16, 2017 at 10:31 AM, Eric Friedrich (efriedri)
 wrote:
> Hello All,
>
> I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 
> (RC6)
>
> Changes since 1.8.1:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1...RELEASE-2.0.0-RC6
>
> This corresponds to git:
> Hash: 85d14ebe2a4ac71236f86f70349481d2b3dc784b
> Tag: RELEASE-2.0.0-RC6
>
> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC6
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC6
>
>
> Docs are available here: https://trafficcontrol.apache.org/docs/2.0.x/
>
>
> The vote will remain open until Friday, June 21, 2017.
>
>
> Thanks,
> Eric Friedrich

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC5)

[Dan Kirkwood]

-1 -- I neglected to remove the reference to an rpm on the build
server in the traffic_ops installation doc.   That won't go over well
with the IPMC.

Otherwise,  I checked:
- signature -- issue with that
+ tarball is correctly named and extracts correct structure
+ md5 and sha512 checksums good
+ builds from source extracted from tarball
+ rpm for traffic_ops installs on clean machine

-dan

On Thu, Jun 15, 2017 at 1:41 PM, Dan Kirkwood <dang...@gmail.com> wrote:
> I checked the signature,  but didn't get Eric's key from the gpg
> refresh.   He's looking into that now..
>
> Meanwhile,  I'm going to build and install fresh.
>
> btw,  Eric -- the Changes section above should be:
>> Changes since 1.8.1:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1...RELEASE-2.0.0-RC5
>
> -dan
>
> On Thu, Jun 15, 2017 at 12:30 PM, Eric Friedrich (efriedri)
> <efrie...@cisco.com> wrote:
>> Hello All,
>>
>> I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 
>> (RC5)
>>
>> Changes since 1.8.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC5
>>
>> This corresponds to git:
>> Hash: b64848e38a09ee372c9a21a3652ea210962ccffa
>> Tag: RELEASE-2.0.0-RC5
>>
>> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC5
>>
>> My code signing key is available here:
>> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>>
>> and here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>
>> Make sure you refresh from a key server to get all relevant signatures.
>>
>> The source .tar.gz file, pgp signature (.asc signed with my key from
>> above), and md5 and sha512 checksums are provided here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC5
>>
>> Docs are available here: https://trafficcontrol.apache.org/docs/2.0.x/
>>
>>
>> The vote will remain open until Thursday, June 20, 2017.
>>
>> This RC fixes some comments from the IPMC made about 1.8.1 and also some 
>> minor bugs in the post install.
>>
>> Thanks,
>> Eric Friedrich

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC5)

[Dan Kirkwood]

I checked the signature,  but didn't get Eric's key from the gpg
refresh.   He's looking into that now..

Meanwhile,  I'm going to build and install fresh.

btw,  Eric -- the Changes section above should be:
> Changes since 1.8.1:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1...RELEASE-2.0.0-RC5

-dan

On Thu, Jun 15, 2017 at 12:30 PM, Eric Friedrich (efriedri)
 wrote:
> Hello All,
>
> I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 
> (RC5)
>
> Changes since 1.8.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC5
>
> This corresponds to git:
> Hash: b64848e38a09ee372c9a21a3652ea210962ccffa
> Tag: RELEASE-2.0.0-RC5
>
> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC5
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC5
>
> Docs are available here: https://trafficcontrol.apache.org/docs/2.0.x/
>
>
> The vote will remain open until Thursday, June 20, 2017.
>
> This RC fixes some comments from the IPMC made about 1.8.1 and also some 
> minor bugs in the post install.
>
> Thanks,
> Eric Friedrich

[RESULT] [VOTE] Release Apache Traffic Control 1.8.1-incubating

[Dan Kirkwood]

The vote passes with three +1 and no -1 votes.

Thanks!

The Apache Traffic Control (Incubating) team

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC4)

[Dan Kirkwood]

you're right -- it shouldn't..   thanks!

On Thu, Jun 8, 2017 at 10:39 AM, Hank Beatty <hbea...@apache.org> wrote:
> I just realized it is our cdn.conf that doesn't have the secrets in it not
> the default. Still don't think it should error. I'll fix it and submit the
> PR.
>
> On 06/08/2017 11:30 AM, Dan Kirkwood wrote:
>>
>> not that I'm aware of...  please do file an issue for it,  though and
>> attach that to the PR.
>>
>> thanks!  Dan
>>
>> On Thu, Jun 8, 2017 at 9:18 AM, Hank Beatty <hbea...@apache.org> wrote:
>>>
>>> postinstall might still be broken:
>>>
>>> Password for database server admin:
>>> Re-Enter Password for database server admin:
>>> Download Maxmind Database? [yes]:
>>> Download Maxmind Database?: yes
>>> ===/opt/traffic_ops/app/conf/cdn.conf===
>>> Generate a new secret? [yes]:
>>> Generate a new secret?: yes
>>> Number of secrets to keep? [10]:
>>> Number of secrets to keep?: 10
>>> Can't use an undefined value as an ARRAY reference at
>>> /opt/traffic_ops/install/bin/_postinstall line 211,  line 13.
>>>
>>> And I've already started looking into it...
>>>
>>> It is trying to load the secrets from the cdn.conf file. The initial
>>> cdn.conf file doesn't have any secrets. I can fix the _postinstall to
>>> correct this and do a PR.
>>>
>>> Unless someone else has already fixed it or it needs to be done a
>>> different
>>> way.
>>>
>>> Thanks,
>>> Hank
>>>
>>> On 06/05/2017 02:16 PM, Eric Friedrich (efriedri) wrote:
>>>>
>>>>
>>>> Hello All,
>>>>
>>>> I've prepared the next candidate release for incubator-trafficcontrol
>>>> v2.0.0 (RC4)
>>>>
>>>> Changes since 1.8.0:
>>>>
>>>>
>>>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC4<https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC3>
>>>>
>>>> This corresponds to git:
>>>> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
>>>> Tag: RELEASE-2.0.0-RC4
>>>>
>>>> Which can be verified with the following:git tag -v
>>>> RELEASE-2.0.0-RC4
>>>>
>>>> My code signing key is available here:
>>>> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>>>>
>>>> and here:
>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>>>
>>>> Make sure you refresh from a key server to get all relevant signatures.
>>>>
>>>> The source .tar.gz file, pgp signature (.asc signed with my key from
>>>> above), and md5 and sha512 checksums are provided here:
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC4
>>>>
>>>>
>>>> The vote will remain open until Thursday, June 8, 2017.
>>>>
>>>> This RC fixes some packaging issues in RC2 and RC3, there are no other
>>>> changes. The git tag hash is the same, but due to changes in the tarball
>>>> the
>>>> release signatures HAVE changes.
>>>>
>>>> Thanks,
>>>> Eric Friedrich
>>>>
>>>
>

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

Thanks for that feedback -- I'll make sure our release instructions
are clear on those points and remove users@ from any future votes.

> The draft release notes (along with links to artifacts,
> signatures/checksums, and updated documentation) can be found here:
>
> http://trafficcontrol.incubator.apache.org/downloads/

To clarify,  this is misstated: the artifacts for this release are not
there -- they will be placed at that location once the release is
approved and not before.  The previous (approved) release artifacts
are at that location.

-dan


On Mon, Jun 5, 2017 at 3:49 PM, sebb <seb...@gmail.com> wrote:
> On 5 June 2017 at 22:12, Dan Kirkwood <dang...@gmail.com> wrote:
>
> DROPPED user@ list - see below.
>
>> Hello Incubator PMC,
>>
>> The Apache Traffic Control community has voted on and approved a
>> proposal to release Apache Traffic Control 1.8.1-incubating. We now
>> kindly request that the Incubator PMC members review and vote on this
>> incubator release.
>>
>> The VOTE RESULT is here:
>>
>> https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E
>>
>> The draft release notes (along with links to artifacts,
>> signatures/checksums, and updated documentation) can be found here:
>>
>> http://trafficcontrol.incubator.apache.org/downloads/
>
> This is a *public* URL.
> However the release has not yet been approved, so it must *not* be published.
> For the same reason, the email regarding the RC should not be sent to
> the user list.
>
> Also the download page points to
>
> https://dist.apache.org/repos/dist/
>
> The dist repo is a staging repo only, and must not be used for public URLs.
>
>> The git tag for the repository is "RELEASE-1.8.1-RC0":
>> https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0
>>
>> The source distribution (also linked in the release notes) is here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/
>
> That URL is fine for RC vote mails
>
>> Build instructions are included in the BUILD.md file which is included
>> in the source artifact.
>>
>> Artifacts have been signed with the "dang...@apache.org" key listed in:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> That URL is fine for RC vote mails
>
>> Please review and vote:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>>
>>  Dan Kirkwood <dang...@apache.org>
>>
>> -
>> 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
>

[VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

Hello Incubator PMC,

The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 1.8.1-incubating. We now
kindly request that the Incubator PMC members review and vote on this
incubator release.

The VOTE RESULT is here:

https://lists.apache.org/thread.html/c43fe387586c44e2ecbac1f968a146f9a402a328be0f6e9b296fc3c9@%3Cusers.trafficcontrol.apache.org%3E

The draft release notes (along with links to artifacts,
signatures/checksums, and updated documentation) can be found here:

http://trafficcontrol.incubator.apache.org/downloads/

The git tag for the repository is "RELEASE-1.8.1-RC0":
https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.1-RC0

The source distribution (also linked in the release notes) is here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0/

Build instructions are included in the BUILD.md file which is included
in the source artifact.

Artifacts have been signed with the "dang...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Please review and vote:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,

 Dan Kirkwood <dang...@apache.org>

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC4)

[Dan Kirkwood]

+1 -- signature and hashes checked.

All components build from source tarball.

On Mon, Jun 5, 2017 at 12:29 PM, Jeff Elsloo  wrote:
> +1 again. Signature and hashes validate.
> --
> Thanks,
> Jeff
>
>
> On Mon, Jun 5, 2017 at 12:16 PM, Eric Friedrich (efriedri)
>  wrote:
>> Hello All,
>>
>> I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 
>> (RC4)
>>
>> Changes since 1.8.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC4
>>
>> This corresponds to git:
>> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
>> Tag: RELEASE-2.0.0-RC4
>>
>> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC4
>>
>> My code signing key is available here:
>> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>>
>> and here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>
>> Make sure you refresh from a key server to get all relevant signatures.
>>
>> The source .tar.gz file, pgp signature (.asc signed with my key from
>> above), and md5 and sha512 checksums are provided here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC4
>>
>>
>> The vote will remain open until Thursday, June 8, 2017.
>>
>> This RC fixes some packaging issues in RC2 and RC3, there are no other 
>> changes. The git tag hash is the same, but due to changes in the tarball the 
>> release signatures HAVE changes.
>>
>> Thanks,
>> Eric Friedrich

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC3)

[Dan Kirkwood]

unfortunately,  have to -1.

Building traffic_ops from the tarball using docker-compose gives me this error:
traffic_ops_build_1  | The build area has been initialized.
traffic_ops_build_1  | Building the rpm.
traffic_ops_build_1  | error: line 26: Tag takes single token
only: Release:  Not in git repository and no BUILD_NUMBER
present -- aborting!.el7

The tarball is missing the BUILD_NUMBER file which gives it the
- identifier for the rpm.   Using the
docker-compose build method or `./build/build.sh source` will create
the tarball with that file created and included.

-dan


On Mon, Jun 5, 2017 at 9:53 AM, Jeff Elsloo  wrote:
> +1 on this, signature and hashes validate.
> --
> Thanks,
> Jeff
>
>
> On Mon, Jun 5, 2017 at 7:03 AM, Eric Friedrich (efriedri)
>  wrote:
>> Hello All,
>>
>> I've prepared the next candidate release for incubator-trafficcontrol v2.0.0 
>> (RC3)
>>
>> Changes since 1.8.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.1-RC0...RELEASE-2.0.0-RC3
>>
>> This corresponds to git:
>> Hash: 795ea3adf2003dd27523b6b9ff4691f23d41ce30
>> Tag: RELEASE-2.0.0-RC3
>>
>> Which can be verified with the following:git tag -v RELEASE-2.0.0-RC3
>>
>> My code signing key is available here:
>> http://pgp.mit.edu/pks/lookup?op=get=0xF2200BAB9AB7BDD5
>>
>> and here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>>
>> Make sure you refresh from a key server to get all relevant signatures.
>>
>> The source .tar.gz file, pgp signature (.asc signed with my key from
>> above), and md5 and sha512 checksums are provided here:
>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/2.0.0/RC3
>>
>>
>> The vote will remain open until Thursday, June 8, 2017.
>>
>> This RC fixes some packaging issues in RC2, there are no other changes. The 
>> git tag hash is the same, but due to changes in the tarball the release 
>> signatures HAVE changes.
>>
>> Thanks,
>> Eric Friedrich

Re: [VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

With 4 +1 votes and no -1 votes,   this release candidate passes.

I'll send out a vote to the Incubator PMC later today.

thanks!  Dan

On Wed, May 31, 2017 at 4:30 PM, Dan Kirkwood <dang...@apache.org> wrote:
> Hello All,
>
> I've prepared the first candidate release for incubator-trafficcontrol
> v1.8.1 (RC0)
>
> Changes since 1.8.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.0...RELEASE-1.8.1-RC0
>
> This corresponds to git:
>   Hash: cc56e76320f6d63f611d4070a1aca1e82d235a61
>   Tag: RELEASE-1.8.1-RC0
>
> Which can be verified with the following:git tag -v RELEASE-1.8.1-RC0
>
> My code signing key is available here:
> http://pgp.mit.edu/pks/lookup?op=get=0xC4B33C804587A8F0
>
> and here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha512 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0
>
> This release updates the Java version used to build traffic monitor and 
> traffic
> router and updates a javascript library to display tables in traffic ops.
>
> The vote will remain open until Monday, June 5, 2017.
>
> Thanks!

[VOTE] Release Apache Traffic Control 1.8.1-incubating (RC0)

[Dan Kirkwood]

Hello All,

I've prepared the first candidate release for incubator-trafficcontrol
v1.8.1 (RC0)

Changes since 1.8.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.0...RELEASE-1.8.1-RC0

This corresponds to git:
  Hash: cc56e76320f6d63f611d4070a1aca1e82d235a61
  Tag: RELEASE-1.8.1-RC0

Which can be verified with the following:git tag -v RELEASE-1.8.1-RC0

My code signing key is available here:
http://pgp.mit.edu/pks/lookup?op=get=0xC4B33C804587A8F0

and here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Make sure you refresh from a key server to get all relevant signatures.

The source .tar.gz file, pgp signature (.asc signed with my key from
above), and md5 and sha512 checksums are provided here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.1/RC0

This release updates the Java version used to build traffic monitor and traffic
router and updates a javascript library to display tables in traffic ops.

The vote will remain open until Monday, June 5, 2017.

Thanks!

Re: TC 2.1 postinstall errors

[Dan Kirkwood]

Hi,  Amir..

We are using Centos 7.2 for traffic ops installation,  and using
docker-compose to build.  Follow the instructions in `BUILD.md` (at
the top level of trafficcontrol) and then installation instructions in
`traffic_ops/INSTALL.md`.

Today is a holiday in the U.S.,  but I'll check email later today if
you have more questions.

-dan

On Mon, May 29, 2017 at 8:31 AM, Amir Yeshurun  wrote:
> Hi,
>
> I am trying to install TC 2.1 on Centos 6.7.
> The RPM was built from master using the Vagrant build framework.
> I had some dependency issues around cpanm and carton and I had to manually
> install cpanm and upgrade Parse::CPAN::Meta before I managed to
> successfully run Carton and install Perl dependencies.
>
> Eventually, I get these errors from _posinstall (see below)
> Is there something that I am missing?
> Thanks
> /amiry
>
> [root@ops-int app]# /opt/traffic_ops/install/bin/postinstall
> Carton is up to date. (v1.0.28)
> Installing modules using /opt/traffic_ops/app/cpanfile
> Complete! Modules were installed into /opt/traffic_ops/app/local
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
> 100 87.0M  100 87.0M0 0  48.5M  0  0:00:01  0:00:01 --:--:--
> 53.1M
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
>   0640640 0368  0 --:--:-- --:--:-- --:--:--
> 688
> go1.8.1.linux-amd64.tar.gz.sha256
> sha256sum: /dev/fd/63: no properly formatted SHA256 checksum lines found
> Extracting go tarball to /usr/local/go
> Now installing goose
> GO_BINARY: /usr/local/go/bin/go
> Successfully installed goose to /opt/traffic_ops/go/bin/goose
> Warning: Use of "localtime" without parentheses is ambiguous at
> /opt/traffic_ops/install/lib/InstallUtils.pm line 113.
> *Type of arg 1 to keys must be hash (not private variable) at
> /opt/traffic_ops/install/bin/_postinstall line 85, near "$var ) "*
> *Type of arg 1 to keys must be hash (not private variable) at
> /opt/traffic_ops/install/bin/_postinstall line 278, near "$defaultInputs )
> "*
> *Type of arg 1 to keys must be hash (not private variable) at
> /opt/traffic_ops/install/bin/_postinstall line 300, near "$defaultInputs )
> "*
> *Type of arg 1 to push must be array (not hash element) at
> /opt/traffic_ops/install/bin/_postinstall line 350, near "%temp;"*
> Execution of /opt/traffic_ops/install/bin/_postinstall aborted due to
> compilation errors.

Re: TC Contributers to Publish list of Planned/WIP Items for Better Community Sync

[Dan Kirkwood]

I'm also with Dave on using github (preferably not Jira) for tracking
this..Some enterprising individual could use the github api to
produce such a report as well showing what's being worked and what
isn't...

-dan

On Thu, May 25, 2017 at 1:46 PM, Dewayne Richardson  wrote:
> +1 on tracking the Roadmap on Github, the "Labels" in github will make it
> easier to track than a wiki (and even JIRA)
>
> On Thu, May 25, 2017 at 12:39 PM, Shmulik Asafi  wrote:
>
>> I think JIRA/Github are suitable candidates.
>> It will require to decide on some way to tag these items so a convenient
>> filter can produce the desired list (otherwise it will be hidden between
>> lots of JIRAs and no use for anyone)
>>
>> What I personally like about the Wiki option, is that maintaining my list
>> of items will involve only a single page (no mouse clicks); in contrast to
>> JIRA where I'll need to create items and maintain each item in a separate
>> page (many mouse clicks). I'm also more of a list-of-open-bullets guy than
>> a table-with-fixed-columns guy when it comes to viewing information.
>>
>> On the other hand JIRA gives more power when it comes to stuff like
>> order-by filter-by and etc.
>>
>> Ultimately, it's a question of which tool most people imagine will be
>> convenient for them to update and view.
>>
>> On Thu, May 25, 2017 at 7:02 PM, Dave Neuman  wrote:
>>
>> > I am probably opening a can of worms that I don't know if I want to open,
>> > but can't we just use Jira for this (and Github once we move there)?  If
>> > someone is working on something it should be in Jira as an issue that
>> > assigned to that person.  From there you can see who is working on what.
>> > It's not going to be perfect, and everything is not always going to be in
>> > there, but it should be good enough IMO.  I think that would be a better
>> > solution than relying on people to keep a wiki up to date.
>> >
>> > On Thu, May 25, 2017 at 9:54 AM, Durfey, Ryan 
>> > wrote:
>> >
>> > > I am +1 on this.  This dovetails well with the idea of a high-level
>> > > roadmap illustrating active areas of work.
>> > >
>> > > I am open to ideas on what tool to use.  I agree with Shmulik we could
>> > > make this work in the wiki if needed.
>> > >
>> > > Ryan DurfeyM | 303-524-5099
>> > > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com> > > cdn_supp...@comcast.com>
>> > >
>> > >
>> > > From: Shmulik Asafi 
>> > > Reply-To: "dev@trafficcontrol.incubator.apache.org" <
>> > > dev@trafficcontrol.incubator.apache.org>
>> > > Date: Wednesday, May 24, 2017 at 11:54 PM
>> > > To: "dev@trafficcontrol.incubator.apache.org" <
>> > > dev@trafficcontrol.incubator.apache.org>
>> > > Subject: TC Contributers to Publish list of Planned/WIP Items for
>> Better
>> > > Community Sync
>> > >
>> > > Hi All,
>> > >
>> > > During the summit I've suggested to a few people that maybe each TC
>> > > contributer should publish a list of the items she's working on
>> presently
>> > > and planning to work on in the near future.
>> > >
>> > > The goal is to share what "major stuff" is going to happen in the
>> project
>> > > (e.g. Jeff's work on Localized/Edge Traffic Routing; Derek's work on
>> > > Delivery Service configuration; Dave/Matt's work on Lua scripts; etc.).
>> > >
>> > > I think this is very little effort by each contributer and will allow
>> us
>> > to
>> > > be much more synced, make it possible to engage with existing efforts
>> and
>> > > provide a platform to detect conflicting/duplicated efforts. I also
>> think
>> > > this can be a first baby step towards building a roadmap in the long
>> > term.
>> > >
>> > > The few people I talked with seemed open to this idea. I hope others
>> will
>> > > feel the same.
>> > >
>> > > I think Wiki pages is the best place for this, but it can also be in
>> > > JIRA/Git, or whatever appropriate tools Apache provides (it would also
>> be
>> > > cool if we could make RSS feed no changes).
>> > >
>> > > What do you think?
>> > >
>> > > If all support, I'd be happy to create the "framework" for this in
>> > whatever
>> > > tool we choose.
>> > >
>> > > Thanks!
>> > >
>> > > --
>> > > *Shmulik Asafi*
>> > > Qwilt | Work: +972-72-2221692 <+972%2072-222-1692>| Mobile:
>> > > +972-54-6581595
>> > > <+972%2054-658-1595>| shmul...@qwilt.com <
>> > > y...@qwilt.com>
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> *Shmulik Asafi*
>> Qwilt | Work: +972-72-2221692| Mobile: +972-54-6581595| shmul...@qwilt.com
>> 
>>

Re: [VOTE] Move Traffic Control to full GitHub

[Dan Kirkwood]

+1

On Thu, May 18, 2017 at 2:32 PM, Jan van Doorn  wrote:
> In
> https://lists.apache.org/thread.html/5bdb9b073343f49c1d5b85147eb9d260bf7ad15d61384929993c7e1d@%3Cdev.trafficcontrol.apache.org%3E
> Dave
> mentioned that we can now move to "full" GitHub. Some more information in
> that thread if you are not familiar. I would like to call an official vote
> on that.
>
> This vote will be open for at least 72 hours.
>
>  [ ] +1 Move Traffic Control to use full GitHub
>  [ ]  0 No opinion
>  [ ] -1 Do not Move Traffic Control to use full GitHub because...
>
> Rgds,
> JvD

Re: 2.0 release?

[Dan Kirkwood]

Rob removed those from master -- I just merged it.   He'll be
cherry-picking for a 2.0.x PR shortly.

On Wed, May 17, 2017 at 11:13 AM, Dan Kirkwood <dang...@gmail.com> wrote:
> by "HEAD",  I meant "master"...
>
> On Wed, May 17, 2017 at 11:05 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>> yep -- it appears that
>> https://github.com/apache/incubator-trafficcontrol/commit/ad28f33fea62cc5ce2c5a7a667b8cf9f06b7b7a2
>> removed the juju/persistentcookie  dependency which is what used that
>> library.
>>
>> It appears to still be there in HEAD as well,   so that would need to
>> be fixed..   I'll file an issue on it..
>>
>> On Wed, May 17, 2017 at 10:30 AM, Chris Lemmons <alfic...@gmail.com> wrote:
>>> The script only checks what's present in the repo. It's possible that the
>>> backport took the dependency out and we just missed deleting the vendored
>>> files.
>>>
>>> On Wed, May 17, 2017 at 10:21 AM Dave Neuman <neu...@apache.org> wrote:
>>>
>>>> Thanks Chris, I thought the GPL license in the TS dir was taken care of,
>>>> maybe we are missing a backport?
>>>> I will have to take a look at that as time allows.
>>>>
>>>> Dan, if the postinstall changes are too much to backport, we should look at
>>>> documenting what needs to be done to get the software installed, that might
>>>> be sufficient.
>>>>
>>>>
>>>> On Wed, May 17, 2017 at 12:03 PM, Chris Lemmons <alfic...@gmail.com>
>>>> wrote:
>>>>
>>>> > Dave, I haven't run RAT, but I did just run the custom license tool for
>>>> TC
>>>> > and this is what it says:
>>>> >
>>>> > ErrorUnknown-Text!
>>>> > traffic_monitor_golang/common/util/num.go
>>>> > ErrorUnknown-Text!
>>>> > traffic_monitor_golang/traffic_monitor/crconfig/data.go
>>>> > ErrorUnknown-Bourne-Again!
>>>> > traffic_ops/app/db/pg-migration/runwaiter.sh
>>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/LICENSE
>>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/clock.go
>>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/exp.go
>>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/regular.go
>>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/retry.go
>>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>>> > gopkg.in/retry.v1/strategy.go
>>>> > There are problematic licenses.
>>>> >
>>>> > Looks like two go files and one shell file missing it's apache header,
>>>> plus
>>>> > a problematic GPL component.
>>>> >
>>>> > On Wed, May 17, 2017 at 9:46 AM Eric Friedrich (efriedri) <
>>>> > efrie...@cisco.com> wrote:
>>>> >
>>>> > > There is an issue that Jeff E will take care of later this week that
>>>> is a
>>>> > > showstopper.
>>>> > >
>>>> > > Also Dan was going to look into seeing if we needed more post
>>>> > > install/postgres fixes back ported to 2.0.x so it could be useful.
>>>> > >
>>>> > > —Eric
>>>> > >
>>>> > >
>>>> > >
>>>> > > > On May 17, 2017, at 11:02 AM, Dave Neuman <neu...@apache.org> wrote:
>>>> > > >
>>>> > > > Hey All,
>>>> > > > We had some great discussion about the 2.0 release at the summit, I
>>>> was
>>>> > > > wondering if anyone had a summary of that discussion and a list of
>>>> > what's
>>>> > > > left to do that could be added to this thread?  I think we discussed
>>>> > that
>>>> > > > we were going to take another look at 2.0 and see if it is a viable
>>>> > > release
>>>> > > > that we should move forward with, is that everyone else's
>>>> understanding
>>>> > > as
>>>> > > > well?

Re: [VOTE] Adding a CHANGELOG.md file

[Dan Kirkwood]

yeah -- what Hank said...

On Wed, May 17, 2017 at 11:17 AM, Hank Beatty  wrote:
> -1 for a manual changelog - doing a compare between branches/commits in
> github is relatively simple.
>
> +1 for a scripted changelog -
> https://github.com/skywinder/github-changelog-generator - There is even a
> list of alternatives:
> https://github.com/skywinder/Github-Changelog-Generator/wiki/Alternatives
>
> On 05/17/2017 12:52 PM, Phil Sorber wrote:
>>
>> Here is a link to an example script generated CHANGES file from Jira:
>>
>> https://raw.githubusercontent.com/apache/trafficserver/6.0.x/CHANGES
>>
>> On Wed, May 17, 2017 at 10:48 AM Phil Sorber  wrote:
>>
>>> The script can be updated to do Jira. ATS used a Jira version before they
>>> went to github. You can also separate out easily. In fact, we did it more
>>> easily with Jira than with github, since those categories are mutually
>>> exclusive in Jira and labels in github are not. You could also have a
>>> developer run the script regularly, or have CI do it.
>>>
>>> To Eric's comment, if you can make that indication in Jira/GitHub then
>>> you
>>> can transition that to the script. For example, a "Changelog" label in
>>> github that would mean to have it included.
>>>
>>> On Wed, May 17, 2017 at 10:37 AM Eric Friedrich (efriedri) <
>>> efrie...@cisco.com> wrote:
>>>
 What about a compromise where developer chooses whether or not a
 feature/important fix is worth mentioning in the release notes. This
 would
 be at feature granularity not individual commit.

 Then at release build time, a script gathers from JIRA/Github API all
 fixes that were committed in that release and checks that into repo.

 —Eric

> On May 17, 2017, at 12:18 PM, Phil Sorber  wrote:
>
> Don't we have a script that can generate this? ATS had this for a long

 time
>
> and it became a huge hassle. It caused merge conflicts all the time,

 that
>
> while easy to address, were a huge nuisance. It also ended up out of

 date
>
> often.
>
> On Wed, May 17, 2017 at 10:11 AM Gelinas, Derek <

 derek_geli...@comcast.com>
>
> wrote:
>
>> +1 for sure. It'll also give us a way to scan the notes and see what

 needs
>>
>> documenting and what doesn't yet have it.
>>
>>> On May 17, 2017, at 11:44 AM, Dave Neuman  wrote:
>>>
>>> Hey All,
>>> One thing we discussed at the meetup was the addition of a

 CHANGELOG.md
>>>
>>> file to the project.   This file will contain changes that are made
>>> to
>>
>> the
>>>
>>> project including bug fixes and new features. (e.g.
>>> https://github.com/influxdata/influxdb/blob/master/CHANGELOG.md).
>>
>> Adding
>>>
>>> this file means that we will now require each PR to contain an update

 to
>>>
>>> the CHANGELOG.md file, and our documentation will need to be updated
>>> accordingly.
>>> I thought it would be good to open a vote for adding this file, and

 if it
>>>
>>> passes, I will update the documentation and add a CHANGELOG.md file.
>>>
>>> Thanks,
>>> Dave
>>
>>


>>
>

Re: 2.0 release?

[Dan Kirkwood]

by "HEAD",  I meant "master"...

On Wed, May 17, 2017 at 11:05 AM, Dan Kirkwood <dang...@gmail.com> wrote:
> yep -- it appears that
> https://github.com/apache/incubator-trafficcontrol/commit/ad28f33fea62cc5ce2c5a7a667b8cf9f06b7b7a2
> removed the juju/persistentcookie  dependency which is what used that
> library.
>
> It appears to still be there in HEAD as well,   so that would need to
> be fixed..   I'll file an issue on it..
>
> On Wed, May 17, 2017 at 10:30 AM, Chris Lemmons <alfic...@gmail.com> wrote:
>> The script only checks what's present in the repo. It's possible that the
>> backport took the dependency out and we just missed deleting the vendored
>> files.
>>
>> On Wed, May 17, 2017 at 10:21 AM Dave Neuman <neu...@apache.org> wrote:
>>
>>> Thanks Chris, I thought the GPL license in the TS dir was taken care of,
>>> maybe we are missing a backport?
>>> I will have to take a look at that as time allows.
>>>
>>> Dan, if the postinstall changes are too much to backport, we should look at
>>> documenting what needs to be done to get the software installed, that might
>>> be sufficient.
>>>
>>>
>>> On Wed, May 17, 2017 at 12:03 PM, Chris Lemmons <alfic...@gmail.com>
>>> wrote:
>>>
>>> > Dave, I haven't run RAT, but I did just run the custom license tool for
>>> TC
>>> > and this is what it says:
>>> >
>>> > ErrorUnknown-Text!
>>> > traffic_monitor_golang/common/util/num.go
>>> > ErrorUnknown-Text!
>>> > traffic_monitor_golang/traffic_monitor/crconfig/data.go
>>> > ErrorUnknown-Bourne-Again!
>>> > traffic_ops/app/db/pg-migration/runwaiter.sh
>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/LICENSE
>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/clock.go
>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/exp.go
>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/regular.go
>>> > ErrorGPL/LGPL! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/retry.go
>>> > Error   GPL/LGPL~! traffic_stats/vendor/
>>> > gopkg.in/retry.v1/strategy.go
>>> > There are problematic licenses.
>>> >
>>> > Looks like two go files and one shell file missing it's apache header,
>>> plus
>>> > a problematic GPL component.
>>> >
>>> > On Wed, May 17, 2017 at 9:46 AM Eric Friedrich (efriedri) <
>>> > efrie...@cisco.com> wrote:
>>> >
>>> > > There is an issue that Jeff E will take care of later this week that
>>> is a
>>> > > showstopper.
>>> > >
>>> > > Also Dan was going to look into seeing if we needed more post
>>> > > install/postgres fixes back ported to 2.0.x so it could be useful.
>>> > >
>>> > > —Eric
>>> > >
>>> > >
>>> > >
>>> > > > On May 17, 2017, at 11:02 AM, Dave Neuman <neu...@apache.org> wrote:
>>> > > >
>>> > > > Hey All,
>>> > > > We had some great discussion about the 2.0 release at the summit, I
>>> was
>>> > > > wondering if anyone had a summary of that discussion and a list of
>>> > what's
>>> > > > left to do that could be added to this thread?  I think we discussed
>>> > that
>>> > > > we were going to take another look at 2.0 and see if it is a viable
>>> > > release
>>> > > > that we should move forward with, is that everyone else's
>>> understanding
>>> > > as
>>> > > > well?
>>> > > > Does anyone know of any showstopper issues that still exist?
>>> > > >
>>> > > > Thanks,
>>> > > > Dave
>>> > > >
>>> > > > On Mon, Apr 10, 2017 at 9:19 PM, Eric Friedrich (efriedri) <
>>> > > > efrie...@cisco.com> wrote:
>>> > > >
>>> > > >> Update:
>>> > > >>  - License issue has been fixed- Thanks Rob!
>>> > > >>  - Posti

Re: 2.0 release?

[Dan Kirkwood]

yep -- it appears that
https://github.com/apache/incubator-trafficcontrol/commit/ad28f33fea62cc5ce2c5a7a667b8cf9f06b7b7a2
removed the juju/persistentcookie  dependency which is what used that
library.

It appears to still be there in HEAD as well,   so that would need to
be fixed..   I'll file an issue on it..

On Wed, May 17, 2017 at 10:30 AM, Chris Lemmons <alfic...@gmail.com> wrote:
> The script only checks what's present in the repo. It's possible that the
> backport took the dependency out and we just missed deleting the vendored
> files.
>
> On Wed, May 17, 2017 at 10:21 AM Dave Neuman <neu...@apache.org> wrote:
>
>> Thanks Chris, I thought the GPL license in the TS dir was taken care of,
>> maybe we are missing a backport?
>> I will have to take a look at that as time allows.
>>
>> Dan, if the postinstall changes are too much to backport, we should look at
>> documenting what needs to be done to get the software installed, that might
>> be sufficient.
>>
>>
>> On Wed, May 17, 2017 at 12:03 PM, Chris Lemmons <alfic...@gmail.com>
>> wrote:
>>
>> > Dave, I haven't run RAT, but I did just run the custom license tool for
>> TC
>> > and this is what it says:
>> >
>> > ErrorUnknown-Text!
>> > traffic_monitor_golang/common/util/num.go
>> > ErrorUnknown-Text!
>> > traffic_monitor_golang/traffic_monitor/crconfig/data.go
>> > ErrorUnknown-Bourne-Again!
>> > traffic_ops/app/db/pg-migration/runwaiter.sh
>> > ErrorGPL/LGPL! traffic_stats/vendor/
>> > gopkg.in/retry.v1/LICENSE
>> > Error   GPL/LGPL~! traffic_stats/vendor/
>> > gopkg.in/retry.v1/clock.go
>> > Error   GPL/LGPL~! traffic_stats/vendor/
>> > gopkg.in/retry.v1/exp.go
>> > ErrorGPL/LGPL! traffic_stats/vendor/
>> > gopkg.in/retry.v1/regular.go
>> > ErrorGPL/LGPL! traffic_stats/vendor/
>> > gopkg.in/retry.v1/retry.go
>> > Error   GPL/LGPL~! traffic_stats/vendor/
>> > gopkg.in/retry.v1/strategy.go
>> > There are problematic licenses.
>> >
>> > Looks like two go files and one shell file missing it's apache header,
>> plus
>> > a problematic GPL component.
>> >
>> > On Wed, May 17, 2017 at 9:46 AM Eric Friedrich (efriedri) <
>> > efrie...@cisco.com> wrote:
>> >
>> > > There is an issue that Jeff E will take care of later this week that
>> is a
>> > > showstopper.
>> > >
>> > > Also Dan was going to look into seeing if we needed more post
>> > > install/postgres fixes back ported to 2.0.x so it could be useful.
>> > >
>> > > —Eric
>> > >
>> > >
>> > >
>> > > > On May 17, 2017, at 11:02 AM, Dave Neuman <neu...@apache.org> wrote:
>> > > >
>> > > > Hey All,
>> > > > We had some great discussion about the 2.0 release at the summit, I
>> was
>> > > > wondering if anyone had a summary of that discussion and a list of
>> > what's
>> > > > left to do that could be added to this thread?  I think we discussed
>> > that
>> > > > we were going to take another look at 2.0 and see if it is a viable
>> > > release
>> > > > that we should move forward with, is that everyone else's
>> understanding
>> > > as
>> > > > well?
>> > > > Does anyone know of any showstopper issues that still exist?
>> > > >
>> > > > Thanks,
>> > > > Dave
>> > > >
>> > > > On Mon, Apr 10, 2017 at 9:19 PM, Eric Friedrich (efriedri) <
>> > > > efrie...@cisco.com> wrote:
>> > > >
>> > > >> Update:
>> > > >>  - License issue has been fixed- Thanks Rob!
>> > > >>  - Postinstall script is broken, Jeff and Dan are looking at it.
>> > > >>
>> > > >> Once post install is fixed, I will cut an RC
>> > > >>
>> > > >> —Eric
>> > > >>
>> > > >>
>> > > >>
>> > > >>> On Apr 6, 2017, at 2:35 PM, Dewayne Richardson <dewr...@gmail.com>
>> > > >> wrote:
>> > > >>>
>> > > >>> +1
>>

Re: Moving Traffic Control the "full" github

[Dan Kirkwood]

+1 here as well..

On Wed, May 17, 2017 at 9:38 AM, Eric Friedrich (efriedri)
 wrote:
> I am all for one less tool to use. Also I think it will lower bar to bringing 
> more people into our project if they don’t have to sign up for the ASF JIRA 
> separately.
>
> —Eric
>
>> On May 17, 2017, at 10:57 AM, Mark Torluemke  wrote:
>>
>> Also +1. Part of the move from github.com/Comcast to ASF JIRA included a
>> 'scrub', so the move to github.com/apache can likely be scripted.
>>
>> On Wed, May 17, 2017 at 8:55 AM, Robert Butts 
>> wrote:
>>
>>> +1
>>>
>>> IMO Github issues, wiki, etc are much, much easier to use than Atlassian
>>> tools.
>>>
>>> On Wed, May 17, 2017 at 8:51 AM, Dave Neuman  wrote:
>>>
 While at ApaceCon, a few of us attended a talk about navigating the
 incubator where we were informed that "full" Github is now available for
 podlings.  This gives us the ability to use github issues, to use github
 wiki, to assign PRs, to add tags to PRs, and the "merge PR" button among
 other things.  It sounds like the process would take our repo down for a
 short period - minutes not hours - but the URL shouldn't change.  I know
>>> we
 just got all of our issues moved to Jira, but we would need to move them
 over to github as well.

 Since the apache way is to have a discussion before a vote, I thought I
 would start the discussion on this topic now and if we feel like this is
 worth pursuing, we start a vote.  Sothoughts?


 Thanks,
 Dave

>>>
>

Re: Goose installer script

[Dan Kirkwood]

It's not a trivial problem.  Yes -- we could include the source --
goose itself is actually fairly small and MIT licensed.   Its
dependencies have licenses that would need to be vetted,   so
vendoring is also not trivial -- no matter how many lines of code are
involved.

We could potentially compile goose and distribute within the rpm --
I've also suggested that before.   Unfortunately,  we have a migration
written in go,  which requires a go installation at run time.That
means the requirement of a go installation is not avoidable without
rewriting that as .sql.

There are alternatives we could use that may not suffer from the same issues.

I suggest we sit down together at the Summit and decide where to go with this..

-dan

On Mon, May 1, 2017 at 10:37 AM, Robert Butts <robert.o.bu...@gmail.com> wrote:
> +1 on Vendoring. I don't see a difference if it's 375,000 lines or
> 10,000,000 lines. What does it matter if it's 375k lines in someone else's
> repo or our own? It does matter from a security standpoint. It means we're
> now vulnerable if their repo is compromised. We shouldn't be pulling
> _anything_ from the internet at install time.
>
> Question for the Apache Gurus: If we include the Goose source, can we also
> include a binary built from that source? I don't see a legal or
> philosophical reason we shouldn't be able to, if we include a hash of the
> binary and the LICENSE file. That lets us avoid requiring Go as a
> dependency, which is difficult since few package managers have a modern Go
> package. Goose is MIT,
> https://www.apache.org/dev/licensing-howto.html#binary suggests we can, yes?
>
>
> On Mon, May 1, 2017 at 8:31 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>
>> ughh.. I'd forgotten I'd done that in all this..
>>
>> Again -- catch-22.
>>
>>
>>
>> On Sun, Apr 30, 2017 at 10:20 PM, Mark Torluemke <mtorlue...@apache.org>
>> wrote:
>> > On Sun, Apr 30, 2017 at 7:05 PM, Gelinas, Derek <
>> derek_geli...@comcast.com>
>> > wrote:
>> >
>> >> +1 on both of these.
>> >>
>> >> > On Apr 30, 2017, at 8:50 PM, Eric Friedrich (efriedri) <
>> >> efrie...@cisco.com> wrote:
>> >> >
>> >> > Assuming we stick with goose, why not bundle goose source into the
>> >> traffic ops RPM? This will pin the version for us and prevent users from
>> >> needing to run go get
>> >>
>> >
>> > Dan had put in a PR to add the Goose source:
>> > https://github.com/apache/incubator-trafficcontrol/pull/157
>> >
>> > We ended up closing it, as 375,000 lines felt a bit excessive...
>> >
>> >
>> >
>> >> >
>> >> > We are allowed to bundle code with the MIT license into our releases.
>> >> >
>> >> > As for the go installation, what about modifying the RPM spec file to
>> >> list GoLang as a dependency of the traffic ops RPM?
>> >> >
>> >> > —Eric
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >> On Apr 28, 2017, at 4:46 PM, Dewayne Richardson <dewr...@gmail.com>
>> >> wrote:
>> >> >>
>> >> >> They are, but makes the tooling easier if we are all in Golang
>> >> >>
>> >> >>> On Fri, Apr 28, 2017 at 1:44 PM, Dave Neuman <neu...@apache.org>
>> >> wrote:
>> >> >>>
>> >> >>> I don't see why re-writing the APIs in something like golang would
>> mean
>> >> >>> that we also need to re-write the database admin script.  I think
>> >> those two
>> >> >>> things are mutually exclusive, right?
>> >> >>>
>> >> >>> On Fri, Apr 28, 2017 at 12:29 PM, Dewayne Richardson <
>> >> dewr...@gmail.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> I had that thought, as well as there are more recent versions like
>> >> >>>> https://github.com/mattes/migrate.  The question becomes if we
>> ever
>> >> get
>> >> >>>> around to rewriting TrafficOps APIs in golang, will the Perl
>> version
>> >> then
>> >> >>>> become obsolete?
>> >> >>>>
>> >> >>>>> On Fri, Apr 28, 2017 at 11:58 AM, Dave Neuman <neu...@apache.org>
>> >> wrote:
>> >> >>>>>
>> >> >>>>> Maybe it'

Re: Goose installer script

[Dan Kirkwood]

ughh.. I'd forgotten I'd done that in all this..

Again -- catch-22.



On Sun, Apr 30, 2017 at 10:20 PM, Mark Torluemke  wrote:
> On Sun, Apr 30, 2017 at 7:05 PM, Gelinas, Derek 
> wrote:
>
>> +1 on both of these.
>>
>> > On Apr 30, 2017, at 8:50 PM, Eric Friedrich (efriedri) <
>> efrie...@cisco.com> wrote:
>> >
>> > Assuming we stick with goose, why not bundle goose source into the
>> traffic ops RPM? This will pin the version for us and prevent users from
>> needing to run go get
>>
>
> Dan had put in a PR to add the Goose source:
> https://github.com/apache/incubator-trafficcontrol/pull/157
>
> We ended up closing it, as 375,000 lines felt a bit excessive...
>
>
>
>> >
>> > We are allowed to bundle code with the MIT license into our releases.
>> >
>> > As for the go installation, what about modifying the RPM spec file to
>> list GoLang as a dependency of the traffic ops RPM?
>> >
>> > —Eric
>> >
>> >
>> >
>> >
>> >
>> >> On Apr 28, 2017, at 4:46 PM, Dewayne Richardson 
>> wrote:
>> >>
>> >> They are, but makes the tooling easier if we are all in Golang
>> >>
>> >>> On Fri, Apr 28, 2017 at 1:44 PM, Dave Neuman 
>> wrote:
>> >>>
>> >>> I don't see why re-writing the APIs in something like golang would mean
>> >>> that we also need to re-write the database admin script.  I think
>> those two
>> >>> things are mutually exclusive, right?
>> >>>
>> >>> On Fri, Apr 28, 2017 at 12:29 PM, Dewayne Richardson <
>> dewr...@gmail.com>
>> >>> wrote:
>> >>>
>>  I had that thought, as well as there are more recent versions like
>>  https://github.com/mattes/migrate.  The question becomes if we ever
>> get
>>  around to rewriting TrafficOps APIs in golang, will the Perl version
>> then
>>  become obsolete?
>> 
>> > On Fri, Apr 28, 2017 at 11:58 AM, Dave Neuman 
>> wrote:
>> >
>> > Maybe it's time we take a look at what goose really buys us and
>> >>> consider
>> > writing our own database migration tool.  We already have admin.pl,
>> it
>> > could probably fit in with that?
>> >
>> > On Fri, Apr 28, 2017 at 11:45 AM, Eric Friedrich (efriedri) <
>> > efrie...@cisco.com> wrote:
>> >
>> >> Hey Dew-
>> >> What calls this script?
>> >>
>> >> If its called from the Traffic Ops Spec file, then this will cause
>> >>> some
>> >> pain for those of us that need to install without internet access.
>> >>
>> >> —Eric
>> >>
>> >>> On Apr 28, 2017, at 12:41 PM, Dewayne Richardson <
>> >>> dewr...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I'm working toward a more streamlined installation process for
>>  Traffic
>> >> Ops
>> >>> (internally) and publicly. Of course, the same hiccups that
>> >>> everyone
>> > else
>> >>> runs into I am as well.  Installation of Golang (proper version)
>> >>> and
>> >>> installation of Goose.  Goose has been the most challenging for
>>  several
>> >>> reasons.  The maintainer hasn't made any real changes since 2015,
>> >>> and
>> > has
>> >>> not "branched" his code to allow for explicit version download.
>> >>> Per
>> > his
>> >>> installation instructions "go get bitbucket.org/liamstask/goose/
>> >> cmd/goose"
>> >>>
>> >>> So I'm I'm proposing to write an installer script in bash to help
>> >> automate
>> >>> the Golang install as well as the Goose install.  My only concern
>> >>> (as
>> >> well
>> >>> as most of yours) is "go get" will grab the latest, but since no
>> >>> real
>> >>> changes have happened I'm left with no other option.
>> >>>
>> >>> Proposed:
>> >>>
>> >>> /opt/traffic_ops/install/bin/install_goose.sh
>> >>>
>> >>> - Install Golang (version 1.8.x)
>> >>> - go get bitbucket.org/liamstask/goose/cmd/goose
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> -Dew
>> >>
>> >>
>> >
>> 
>> >>>
>> >
>>

Re: 2.0 release?

[Dan Kirkwood]

+1

On Thu, Apr 6, 2017 at 7:43 AM, David Neuman  wrote:
> Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet
> released, why don't we just remove the `ResumeSession` method all together
> and eliminate the dependency?  Otherwise we are deprecating something that
> we never formally released.
>
> On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts 
> wrote:
>
>> Regarding `TC-119: traffic_ops/client dependency license issue`:
>>
>> It looks like the persistent cookie jar is only needed by Traffic Ops
>> Client `ResumeSession(toURL string, insecure bool) (*Session, error)`.
>> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone else is
>> using it. Because it returns an error, and persisted cookies have
>> lifetimes, any current users already must handle errors from persisted
>> cookies being expired. Thus, we can change it to always return an error
>> with only degraded performance (and not much, login is cheap), without loss
>> of functionality.
>>
>> To fix TC-119, I propose we document `ResumeSession` as deprecated, and
>> change it to always return an error, which lets us remove the dependency,
>> without the development cost of writing our own persistent cookie store
>> that no one is using.
>>
>> Any objections?
>>
>>
>> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell 
>> wrote:
>>
>> > These all got fixed and backported to 2.0:
>> >
>> > TC-203: Mojo doesn’t set cachable headers on public files”
>> > TC-190: TTL type mismatch in CrConfig
>> > TC-189: ssl_multicert.config too slow
>> >
>> > So Jan and Dave just need to close the issues.
>> >
>> > On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin > >
>> > wrote:
>> >
>> > > Hi Eric,
>> > > I was going to address the immediate Postinstall issues TC-185. I am
>> way
>> > > late on this. I created a fork yesterday, need to run a couple of tests
>> > and
>> > > then I can push to this fork.
>> > > Jeff Martin
>> > >
>> > >
>> > > On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) <
>> > > efrie...@cisco.com> wrote:
>> > >
>> > > > We have some release blockers for 2.0. Specifically:
>> > > >
>> > > > TC-119: traffic_ops/client dependency license issue
>> > > > We cannot ship with Category-X LGPL software, so I’m waiting for
>> > this
>> > > > to be resolved before cutting a release branch
>> > > >  "TC-185 post install doesn’t run due to missing perl module”
>> > > > We shouldn’t ship a release in which the install process is
>> broken
>> > in
>> > > > this way.
>> > > >*There’s no assignee yet for this, any volunteers?*
>> > > >
>> > > > I think if we can get those two taken care of we can cut an RC0 later
>> > > this
>> > > > week.
>> > > >
>> > > > Major bugs we will ship with (unless someone objects):
>> > > > TC-203: Mojo doesn’t set cachable headers on public files”
>> > > > TC-190: TTL type mismatch in CrConfig
>> > > > TC-189: ssl_multicert.config too slow
>> > > >
>> > > > —Eric
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > On Apr 4, 2017, at 1:13 PM, Dave Neuman  wrote:
>> > > > >
>> > > > > Good question.  I would also like to see us try to get some release
>> > > > > candidates out for 2.0.  I am pretty sure the actual install and
>> > > > > postinstall need work.  There are also a couple of issue that are
>> > still
>> > > > > assigned to 2.0 and unresolved:
>> > > > > https://issues.apache.org/jira/browse/TC/fixforversion/
>> > > > 12338562/?selectedTab=com.atlassian.jira.jira-projects-
>> > > > plugin:version-summary-panel
>> > > > > .
>> > > > >
>> > > > > On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn 
>> > > wrote:
>> > > > >
>> > > > >> When are we planning to release 2.0? We at Comcast are running
>> what
>> > we
>> > > > >> call 2.0…. So we are +1, I am pretty sure.
>> > > > >>
>> > > > >> Eric: are you waiting for something? Which cats need herding?
>> > > > >>
>> > > > >> Rgds,
>> > > > >> JvD
>> > > > >>
>> > > > >>
>> > > >
>> > > >
>> > >
>> >
>>

[ANNOUNCE] Release Apache Traffic Control 1.8.0 (incubating)

[Dan Kirkwood]

The Apache Traffic Control team would like to announce the release of
Apache Traffic Control 1.8.0 (incubating).

More details regarding Apache Traffic Control can be found at:
http://trafficcontrol.incubator.apache.org/

The release artifacts can be downloaded here:
https://dist.apache.org/repos/dist/release/incubator/trafficcontrol/1.8.0-incubating/

The release notes can be found here:
http://trafficcontrol.incubator.apache.org/downloads/index.html

Thanks!
The Apache Traffic Control Team


Apache Traffic Control is an effort undergoing Incubation at The
Apache Software Foundation (ASF), sponsored by the Incubator.
Incubation is required of all newly accepted projects until a further
review indicates that the infrastructure, communications, and decision
making process have stabilized in a manner consistent with other
successful ASF projects. While incubation status is not necessarily a
reflection of the completeness or stability of the code, it does
indicate that the project has yet to be fully endorsed by the ASF.

Re: Traffic Control Wiki Organization

[Dan Kirkwood]

+1


On Fri, Mar 3, 2017 at 4:59 PM, Jeremy Mitchell  wrote:
> thanks for doing that, Ashish. I would say go ahead and move pages to where
> they seem appropriate. That would be a great starting point. thanks again.
>
> Jeremy
>
> On Fri, Mar 3, 2017 at 10:44 AM, Durfey, Ryan 
> wrote:
>
>> Thanks Ashish for moving in all the old wiki pages from github!
>>
>> I was going to wait for page creators to review and organize but I realize
>> everyone is very busy.  If there are no objections by Monday morning, we
>> will move wiki pages to the new locations they appear to fit best.  If
>> someone finds something out of place feel free to correct.
>>
>> Ryan Durfey M | 303-524-5099
>>
>>
>> From: Ryan Durfey 
>> Date: Thursday, March 2, 2017 at 7:50 AM
>> To: "dev@trafficcontrol.incubator.apache.org" <
>> dev@trafficcontrol.incubator.apache.org>
>> Subject: Re: Traffic Control Wiki Organization
>>
>> Thanks Jeremy!  Great feedback. ☺
>>
>> Old Wiki:
>> I will work with Ashish to pull in all the existing pages from the old
>> Wiki and then the page stakeholders can decide on relevance, naming, and
>> organization.
>>
>> Published Docs vs. Cwiki Documentation:
>> I would argue that the cwiki relates to brainstorming on architecture and
>> development strategy and the published docs in
>> http://trafficcontrol.apache.org are
>> for documentation of completed development, but always open to debate.
>>
>> Organizing Pages:
>> I am happy to organize, but would rather push page creators and key
>> participants to consider the right place for their content so I am not
>> stepping on toes.  If people are good with the organization changes
>> proposed, just send me a note and I am happy to help make changes with at
>> least one key stakeholders consent.
>>
>> Ryan Durfey M | 303-524-5099
>>
>>
>> From: Jeremy Mitchell 
>> Reply-To: "dev@trafficcontrol.incubator.apache.org" <
>> dev@trafficcontrol.incubator.apache.org>
>> Date: Wednesday, March 1, 2017 at 7:39 PM
>> To: "dev@trafficcontrol.incubator.apache.org" <
>> dev@trafficcontrol.incubator.apache.org>
>> Subject: Re: Traffic Control Wiki Organization
>>
>> I think a little organization of the wiki page would prove to be very
>> helpful. Parent pages make sense to me. Also, I would not be opposed to you
>> moving some pages aroundalthough, i suppose that will change the URL of
>> the page, huh? But I still think if we spend a little time getting
>> organized and establishing a pattern, that will make our wiki much more
>> useful going forward.
>>
>> However, I am a bit confused about what goes on
>> http://trafficcontrol.apache.org vs. the wiki.
>>
>> Also, we still have a bunch of pages on the old wiki (
>> https://github.com/Comcast/traffic_control/wiki) that should be migrated
>> if
>> still relevant.
>>
>> Jeremy
>>
>> On Wed, Mar 1, 2017 at 5:58 PM, Durfey, Ryan > mailto:ryan_dur...@comcast.com>>
>> wrote:
>>
>> I have started adding parent pages for each platform like “Traffic Ops” so
>> that articles can be aggregated.  I will add comments to the existing pages
>> suggesting where to move.  Feel free to suggest alternatives.
>>
>> Ryan Durfey M | 303-524-5099
>>
>>
>> From: Ryan Durfey > comcast.com>>
>> Date: Monday, February 27, 2017 at 8:30 AM
>> To: "dev@trafficcontrol.incubator.apache.org> trafficcontrol.incubator.apache.org>" <
>> dev@trafficcontrol.incubator.apache.org> trafficcontrol.incubator.apache.org>>
>> Subject: Traffic Control Wiki Organization
>>
>>
>> I wanted to start some documentation around how pages should be organized
>> and named to make it easier for everyone to find information.  I wasn’t
>> sure whether to start that in an email thread or put it in the wiki for
>> comment so I am doing both.  Happy to help incorporate additional
>> suggestions or modify what I put in as per feedback.
>>
>> https://cwiki.apache.org/confluence/display/TC/Traffic+Control+Home
>>
>> Ryan
>>
>>
>>
>>

docker-compose for builds

[Dan Kirkwood]

Hi all..I've submitted a PR
(https://github.com/apache/incubator-trafficcontrol/pull/327) for
building using docker/docker-compose that eliminates pulling the
source code from github and instead builds from your local source
tree.

There have been questions in the past about the github connection not
being in compliance with Apache guidelines (should be able to build
from the distributed tar ball).

I think this should be pulled in to the 2.0 branch.

Any objections?

thanks!  Dan

[VOTE] Release Apache Traffic Control 1.8.0-incubating (RC11)

[Dan Kirkwood]

Hello Incubator PMC,

The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 1.8.0-incubating.  We now
kindly request that the Incubator PMC members review and vote on this
incubator release.

The VOTE RESULT is here:

https://lists.apache.org/thread.html/dc3ba61d2834579a6e7237df08d828b61011a6cb087e1948be70c78a@%3Cdev.trafficcontrol.apache.org%3E

The draft release notes (along with links to artifacts,
signatures/checksums, and updated documentation) can be found here:

http://trafficcontrol.incubator.apache.org/downloads/

The git tag for the repository is "RELEASE-1.8.0-RC11":
https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.0-RC11

The source distribution (also linked in the release notes) is here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC11/

Build instructions are included in the BUILD.md file which is included
in the source artifact.

Artifacts have been signed with the "dang...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Please review and vote:

[  ] +1 Approve the release
[  ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,

- Dan

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC11)

[Dan Kirkwood]

The vote is now closed and RC11 passes with 5 +1 votes and  no -1 votes.

I'll craft a new vote to the IPMC starting today and ending on Friday.

Thanks, all!

Dan

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC11)

[Dan Kirkwood]

+1 here as well


On Sun, Feb 19, 2017 at 6:43 PM, Jan van Doorn <j...@knutsel.com> wrote:
> +1 based on my earlier vote.
>
> On Feb 19, 2017, at 6:42 PM, Dave Neuman <neu...@apache.org> wrote:
>
> +1, this shows that only license files changed:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.8.0-RC9...RELEASE-1.8.0-RC11
>
> On Sat, Feb 18, 2017 at 10:04 AM, Jeremy Mitchell <mitchell...@gmail.com>
> wrote:
>>
>> +1
>>
>> On Sat, Feb 18, 2017 at 7:26 AM, Hank Beatty <hbea...@apache.org> wrote:
>>>
>>> +1
>>>
>>> Looks like only licenses were changed.
>>>
>>>
>>> On 02/17/2017 03:07 PM, Dan Kirkwood wrote:
>>>>
>>>> Hello All,
>>>>
>>>> I've prepared another release for v1.8.0 (RC11).   I apologize for the
>>>> confusion on RC10 -- we had a glitch in our tagging process.  RC11 is
>>>> identical to RC10,  but we decided to redo the process to ensure the
>>>> integrity of the release.   The source tarballs are identical in
>>>> content -- only dates changed, but the checksums will be different.
>>>>
>>>> Changes since 1.7.0:
>>>>
>>>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC11
>>>>
>>>> This corresponds to git:
>>>>   Hash: 14ef03fd251b6306e67627c935f9111efb0284af
>>>>   Tag: RELEASE-1.8.0-RC11
>>>>
>>>> Which can be verified with the following:git tag -v
>>>> RELEASE-1.8.0-RC11
>>>>
>>>> My code signing key is available here:
>>>> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>>>>
>>>> Make sure you refresh from a key server to get all relevant signatures.
>>>>
>>>> The source .tar.gz file, pgp signature (.asc signed with my key from
>>>> above), and md5 and sha1 checksums are provided here:
>>>>
>>>>
>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC11
>>>>
>>>> (from RC10): This RC has only LICENSE file changes to eliminate 3rd
>>>> party URLs and
>>>> a small addition to NOTICE to cover binary font files.
>>>>
>>>> The vote will remain open until the evening of Monday, Feb 20, 2017 to
>>>> allow a full 72 hour vetting period.
>>>>
>>>> Thanks!
>>>> Dan
>>>>
>>
>
>

[VOTE] Release Apache Traffic Control 1.8.0-incubating (RC11)

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC11).   I apologize for the
confusion on RC10 -- we had a glitch in our tagging process.  RC11 is
identical to RC10,  but we decided to redo the process to ensure the
integrity of the release.   The source tarballs are identical in
content -- only dates changed, but the checksums will be different.

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC11

This corresponds to git:
  Hash: 14ef03fd251b6306e67627c935f9111efb0284af
  Tag: RELEASE-1.8.0-RC11

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC11

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

The source .tar.gz file, pgp signature (.asc signed with my key from
above), and md5 and sha1 checksums are provided here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC11

(from RC10): This RC has only LICENSE file changes to eliminate 3rd
party URLs and
a small addition to NOTICE to cover binary font files.

The vote will remain open until the evening of Monday, Feb 20, 2017 to
allow a full 72 hour vetting period.

Thanks!
Dan

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC10)

[Dan Kirkwood]

Good thing I waited..Something went wrong with my git clone and a
bunch of changes went in from master...

-1 --  I'll get a new one in tomorrow.

-dan

On Thu, Feb 16, 2017 at 1:35 PM, Dan Kirkwood <dang...@apache.org> wrote:
> ok -- a bit premature..   I'll wait until tomorrow morning -- if you
> need more time,  let me know.
>
> -dan
>
> On Thu, Feb 16, 2017 at 12:39 PM, Dan Kirkwood <dang...@apache.org> wrote:
>> We have 4 +1 already,   so I'm declaring RC10 as passed!
>>
>> I'll send out the email to the IPMC shortly...
>>
>> Thanks all..
>>
>> -dan
>>
>> On Thu, Feb 16, 2017 at 11:50 AM, Dan Kirkwood <dang...@apache.org> wrote:
>>> Hello All,
>>>
>>> I've prepared another release for v1.8.0 (RC10)
>>>
>>> Changes since 1.7.0:
>>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC10
>>>
>>> This corresponds to git:
>>>   Hash: 14ef03fd251b6306e67627c935f9111efb0284af
>>>   Tag: RELEASE-1.8.0-RC10
>>>
>>> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC10
>>>
>>> My code signing key is available here:
>>> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>>>
>>> Make sure you refresh from a key server to get all relevant signatures.
>>>
>>> The source .tar.gz file, pgp signature (.asc signed with my key from
>>> above), and md5 and sha1 checksums are provided here:
>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC10
>>>
>>> This RC has only LICENSE file changes to eliminate 3rd party URLs and
>>> a small addition to NOTICE to cover binary font files.
>>>
>>> Since the changes are license-related only,   we'd like to keep the
>>> voting period very short.   Please vote by end-of-day today (Thursday,
>>>  Feb 16).  If this is not enough time for you to examine the RC,
>>> please respond and we can extend the vote.
>>>
>>>
>>> Thanks!

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC10)

[Dan Kirkwood]

We have 4 +1 already,   so I'm declaring RC10 as passed!

I'll send out the email to the IPMC shortly...

Thanks all..

-dan

On Thu, Feb 16, 2017 at 11:50 AM, Dan Kirkwood <dang...@apache.org> wrote:
> Hello All,
>
> I've prepared another release for v1.8.0 (RC10)
>
> Changes since 1.7.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC10
>
> This corresponds to git:
>   Hash: 14ef03fd251b6306e67627c935f9111efb0284af
>   Tag: RELEASE-1.8.0-RC10
>
> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC10
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha1 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC10
>
> This RC has only LICENSE file changes to eliminate 3rd party URLs and
> a small addition to NOTICE to cover binary font files.
>
> Since the changes are license-related only,   we'd like to keep the
> voting period very short.   Please vote by end-of-day today (Thursday,
>  Feb 16).  If this is not enough time for you to examine the RC,
> please respond and we can extend the vote.
>
>
> Thanks!

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC10)

[Dan Kirkwood]

+1

I put together the tarball myself,  but also downloaded the tarball
and verified checksums and signature from the downloaded files.   Also
built from source.

Dan

On Thu, Feb 16, 2017 at 11:50 AM, Dan Kirkwood <dang...@apache.org> wrote:
> Hello All,
>
> I've prepared another release for v1.8.0 (RC10)
>
> Changes since 1.7.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC10
>
> This corresponds to git:
>   Hash: 14ef03fd251b6306e67627c935f9111efb0284af
>   Tag: RELEASE-1.8.0-RC10
>
> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC10
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha1 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC10
>
> This RC has only LICENSE file changes to eliminate 3rd party URLs and
> a small addition to NOTICE to cover binary font files.
>
> Since the changes are license-related only,   we'd like to keep the
> voting period very short.   Please vote by end-of-day today (Thursday,
>  Feb 16).  If this is not enough time for you to examine the RC,
> please respond and we can extend the vote.
>
>
> Thanks!

[VOTE] Release Apache Traffic Control 1.8.0-incubating (RC10)

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC10)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC10

This corresponds to git:
  Hash: 14ef03fd251b6306e67627c935f9111efb0284af
  Tag: RELEASE-1.8.0-RC10

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC10

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

The source .tar.gz file, pgp signature (.asc signed with my key from
above), and md5 and sha1 checksums are provided here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC10

This RC has only LICENSE file changes to eliminate 3rd party URLs and
a small addition to NOTICE to cover binary font files.

Since the changes are license-related only,   we'd like to keep the
voting period very short.   Please vote by end-of-day today (Thursday,
 Feb 16).  If this is not enough time for you to examine the RC,
please respond and we can extend the vote.


Thanks!

[VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)

[Dan Kirkwood]

Hello Incubator PMC,

The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 1.8.0-incubating.  We now
kindly request that the Incubator PMC members review and vote on this
incubator release.

The VOTE RESULT is here:

https://lists.apache.org/thread.html/4aa7f70b34ba9d2e4190301ae7ea118aa86b297c81e60467aedaf3dc@%3Cdev.trafficcontrol.apache.org%3E

The draft release notes (along with links to artifacts,
signatures/checksums, and updated documentation) can be found here:

http://trafficcontrol.incubator.apache.org/downloads/

The git tag for the repository is "RELEASE-1.8.0-RC9":
https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.0-RC9

The source distribution (also linked in the release notes) is here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC9/

Build instructions are included in the BUILD.md file which is
included in the source artifact.

Artifacts have been signed with the "dang...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Please review and vote:

[  ] +1 Approve the release
[  ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,

- Dan

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)

[Dan Kirkwood]

+1

-- was assuming as release manager I didn't get a vote,  but not true?

I tested:
-  signature and checksums good
-  build from gitrepo and RC9 tag
- scanning source with `rat` tool shows no license issues
-  install traffic_ops on new Centos 7.2 VM
 -  setup new mysql,  loaded with test data
 -  login from UI,  navigating parts of UI


On Wed, Jan 25, 2017 at 9:15 AM, Dan Kirkwood <dang...@apache.org> wrote:
> Hello All,
>
> I've prepared another release for v1.8.0 (RC9)
>
> Changes since 1.7.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC9
>
> This corresponds to git:
>   Hash: 2301659f699948d9944cc07bc92b9f6a56bc4678
>   Tag: RELEASE-1.8.0-RC9
>
> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC9
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> The source .tar.gz file, pgp signature (.asc signed with my key from
> above), and md5 and sha1 checksums are provided here:
> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC9
>
> More Apache License compliance changes are included in this RC.
> Several third-party javascript files were removed that were deemed
> unused.
>
> The vote will remain open until Friday,  Jan 27, 2017.
>
> Thanks!

[VOTE] Release Apache Traffic Control 1.8.0-incubating (RC8)

[Dan Kirkwood]

Hello Incubator PMC,

The Apache Traffic Control community has voted on and approved a
proposal to release Apache Traffic Control 1.8.0-incubating.  We now
kindly request that the Incubator PMC members review and vote on this
incubator release.

The VOTE RESULT is here:

https://lists.apache.org/thread.html/64b9ffad20aca8a4af3bdb0ce33c2d2a26c24c48d96c31494acdca9d@%3Cdev.trafficcontrol.apache.org%3E

The draft release notes (along with links to artifacts,
signatures/checksums, and updated documentation) can be found here:

http://trafficcontrol.incubator.apache.org/downloads/

The git tag for the repository is "RELEASE-1.8.0-RC8":
https://github.com/apache/incubator-trafficcontrol/releases/tag/RELEASE-1.8.0-RC8

The source distribution (also linked in the release notes) is here:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC8/

Build instructions are included in the BUILD.md file which is
included in the source artifact.

Artifacts have been signed with the "dang...@apache.org" key listed in:

https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/KEYS

Please review and vote:

[  ] +1 Approve the release
[  ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,

- Dan

Re: [VOTE] incubator-trafficcontrol-1.8.0-RC8

[Dan Kirkwood]

And Hank has changed his vote to +1.  The vote passes with 4 +1 and no
-1.I'll send the email out to the incubator.

Thanks, all!  Dan

On Fri, Jan 20, 2017 at 11:49 AM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> +1 on RC8
>
> Here’s what I checked:
> - hashes and signatures good
> - incubating in name
> - tarball builds successfully
> - git tag good
>
> —Eric
>
>> On Jan 19, 2017, at 2:58 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Thanks,   Hank..I don't think the double-license or double-use
>> will have any impact,  but thanks for pointing those out.I'll get
>> that fixed in master.   Still -1?
>>
>> -dan
>>
>> On Thu, Jan 19, 2017 at 12:26 PM, Dave Neuman <neu...@apache.org> wrote:
>>> FYI...Here is a link the converstation on slack.
>>>
>>> http://traffic-control-cdn.slackarchive.io/dev/-/1481579848.000262/1482862383.00037/1482442468000323/
>>>
>>> --Dave
>>>
>>> On Thu, Jan 19, 2017 at 12:22 PM, Dave Neuman <neu...@apache.org> wrote:
>>>
>>>> It also appears the issue I brought up about Traffic Ops not working with
>>>> Riak 2.1.4 hasn't been addressed.
>>>>
>>>> We agreed, I think on email but maybe on slack, that we would document the
>>>> Riak issue in release notes and fix it in the next release. Do you think
>>>> you are ok with that solution?
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>>
>>>> On Thu, Jan 19, 2017 at 11:43 AM, Hank Beatty <hbea...@apache.org> wrote:
>>>>
>>>>> * traffic_ops/app/lib/Schema/Result/SteeringView.pm
>>>>>  * License is in twice
>>>>>  * use strict and use warnings is also in twice
>>>>>
>>>>> It also appears the issue I brought up about Traffic Ops not working with
>>>>> Riak 2.1.4 hasn't been addressed.
>>>>>
>>>>> -1
>>>>>
>>>>>
>>>>> On 01/13/2017 03:57 PM, Dan Kirkwood wrote:
>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> I've prepared another release for v1.8.0 (RC7)
>>>>>>
>>>>>> Changes since 1.7.0:
>>>>>> https://github.com/apache/incubator-trafficcontrol/compare/R
>>>>>> ELEASE-1.7.0...RELEASE-1.8.0-RC8
>>>>>>
>>>>>> This corresponds to git:
>>>>>>  Hash:597e7795c48ab65fe57175642973481b9dc020e6
>>>>>>  Tag: RELEASE-1.8.0-RC8
>>>>>>
>>>>>> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC8
>>>>>>
>>>>>> My code signing key is available here:
>>>>>> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>>>>>>
>>>>>> Make sure you refresh from a key server to get all relevant signatures.
>>>>>>
>>>>>> The source .tar.gz file, pgp signature (.asc signed with my key from
>>>>>> above), and md5 and sha1 checksums are provided here:
>>>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcont
>>>>>> rol/1.8.0/RC8
>>>>>>
>>>>>> More Apache License compliance changes are included in this RC as well
>>>>>> as one critical regression from 1.7:
>>>>>> https://issues.apache.org/jira/browse/TC-97
>>>>>>
>>>>>> The vote will remain open until Wednesday,  Jan 18, 2017.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>
>

[VOTE] incubator-trafficcontrol-1.8.0-RC8

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC7)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC8

This corresponds to git:
  Hash:597e7795c48ab65fe57175642973481b9dc020e6
  Tag: RELEASE-1.8.0-RC8

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC8

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

The source .tar.gz file, pgp signature (.asc signed with my key from
above), and md5 and sha1 checksums are provided here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC8

More Apache License compliance changes are included in this RC as well
as one critical regression from 1.7:
https://issues.apache.org/jira/browse/TC-97

The vote will remain open until Wednesday,  Jan 18, 2017.

Thanks!

Re: [VOTE] incubator-trafficcontrol-1.8.0-RC6

[Dan Kirkwood]

Yes -- you are correct..   I recalled the wording incorrectly. I
just put in https://github.com/apache/incubator-trafficcontrol/pull/169
which changes the name as you suggest and the top-level directory name
with version number..

Thanks for the feedback!  Dan

On Sat, Jan 7, 2017 at 7:41 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Jan 6, 2017, at 2:15 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hello All,
>>
>> I've prepared another release for v1.8.0 (RC6)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC6
>>  
>> <https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC6>
>
> Wasn’t the ruling from IPMC that the word “incubating” must be in the 
> artifact names? I still see “incubation”.
>
> I still personally think you should also include the version number in the 
> top-level directory that the tar-ball unpacks into. So, like
>
> incubating-trafficcontrol-1.8.0
>
>
> Also, while I’m bike shedding, wouldn’t a name like this make more sense?
>
> trafficcontrol-incubating-1.8.0
>
>
> Thoughts?
>
> Cheers,
>
> — leif
>

[VOTE] incubator-trafficcontrol-1.8.0-RC6

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC6)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC6

This corresponds to git:
  Hash: 20d7e37b57b9aa47e7731595641920de268ea219
  Tag: RELEASE-1.8.0-RC6

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC6

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

The source .tar.gz file, pgp signature (.asc signed with my key from
above), and md5 and sha1 checksums are provided here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC6/

The main changes to this release candidate are removal of some Perl
modules and the goose binary and the change of the source tar ball
name as well as the addition of rpm build instructions in BUILD.md.

The vote will remain open until Tuesday,  Jan 10, 2017.

Thanks!

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC5

[Dan Kirkwood]

One correction:  The signed source tarball and checksums are available here:
  https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC5/

[VOTE] Traffic Control RELEASE-1.8.0-RC5

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC5)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC5

This corresponds to git:
  Hash: b30cbc5d32c991e472c082b97f9bfd73a7699c66
  Tag: RELEASE-1.8.0-RC5

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC5

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

Note that we are not providing the RPM files this time.   The only
artifact provided is a source tar file which can be downloaded from
here:

  https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/

Let me know if you need the rpm files and I can make arrangements to
get them to you.

Per Apache guidelines, the .tar.gz file is signed with my pgp key (see
above) and md5 and sha1 checksums are also provided there.

This release candidate encompasses only license header changes,  so we
are keeping the vote open until end of day Thursday, December 22,
2016.

Thanks!

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC4

[Dan Kirkwood]

oy..   yep -- you're right.. We have those licenses on master,
but didn't get in to 1.8.

This would be prevented in the future by a CI process that includes
RAT,   but I guess there's going to be a RC5...

-dan

On Tue, Dec 20, 2016 at 8:52 AM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Dec 8, 2016, at 12:58 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hello All,
>>
>> I've prepared another release for v1.8.0 (RC4)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC4
>>
>> This corresponds to git:
>>  Hash: 7d8a88d0512ffe0354c2bc079ddbf2e7b67b6c3e
>>  Tag: RELEASE-1.8.0-RC4
>>
>> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC4
>>
>> My code signing key is available here:
>> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>>
>> Make sure you refresh from a key server to get all relevant signatures.
>>
>> Note that we are not providing the RPM files this time.   The only
>> artifact provided is a source tar file which can be downloaded from
>> here:
>>
>>  https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/ 
>> <https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/>
>
>
> Hmmm, are we ok with the ~200 RAT warnings? I ran:
>
> java -jar ~/apache/trafficserver.git/ci/apache-rat-0.11-SNAPSHOT.jar 
> -d . -E .rat-excludes
>
>
> See output below. I also wish we’d put the version number in the base dir in 
> the tar ball, but that’s definitely not a show stopper. If the RAT report 
> below is what you expect (i.e. they are covered by a NOTICE), then things 
> look good to ship for me. But long term, we should aim to have a clean RAT 
> report, even if it means adding more stuff to the .rat-excludes.
>
> Cheers,
>
> — Leif
>
>
> *
> Summary
> ---
> Generated at: 2016-12-20T08:46:43-07:00
> Notes: 0
> Binaries: 0
> Archives: 0
> Standards: 1217
>
> Apache Licensed: 1002
> Generated Documents: 0
>
> JavaDocs are generated and so license header is optional
> Generated files do not required license headers
>
> 215 Unknown Licenses
>
> ***
>
> Unapproved licenses:
>
>   ./infrastructure/test/api/traffic_ops/traffic_ops_test.go
>   ./infrastructure/test/api/traffic_ops/traffic_ops_tester.go
>   ./infrastructure/test/apitest/apitest.go
>   ./infrastructure/test/environment/environment.go
>   ./infrastructure/test/ui/traffic_ops/traffic_ops_test.go
>   ./test/router/index.html
>   ./test/router/client/client.go
>   ./test/router/data/httpresult.go
>   ./test/router/dnssec/dnssec.go
>   ./test/router/dnssec/dnssec_suite_test.go
>   ./test/router/dnssec/dnssec_test.go
>   ./test/router/load/load.go
>   ./test/router/server/server.go
>   ./traffic_monitor/pom.xml
>   ./traffic_monitor/build/pmd/ruleset.xml
>   ./traffic_monitor/experimental/common/adapter/adapter.go
>   ./traffic_monitor/experimental/common/crstates/crstates.go
>   ./traffic_monitor/experimental/common/fetcher/fetcher.go
>   ./traffic_monitor/experimental/common/handler/handler.go
>   ./traffic_monitor/experimental/common/instrumentation/instrumentation.go
>   ./traffic_monitor/experimental/common/log/log.go
>   ./traffic_monitor/experimental/common/poller/poller.go
>   ./traffic_monitor/experimental/traffic_monitor/build.sh
>   ./traffic_monitor/experimental/traffic_monitor/index.html
>   ./traffic_monitor/experimental/traffic_monitor/traffic_monitor.go
>   ./traffic_monitor/experimental/traffic_monitor/version.go
>   ./traffic_monitor/experimental/traffic_monitor/cache/astats.go
>   ./traffic_monitor/experimental/traffic_monitor/cache/astats_test.go
>   ./traffic_monitor/experimental/traffic_monitor/cache/cache.go
>   ./traffic_monitor/experimental/traffic_monitor/config/config.go
>   ./traffic_monitor/experimental/traffic_monitor/deliveryservice/stat.go
>   ./traffic_monitor/experimental/traffic_monitor/deliveryservicedata/stat.go
>   ./traffic_monitor/experimental/traffic_monitor/enum/enum.go
>   ./traffic_monitor/experimental/traffic_monitor/health/cache_health.go
>   
> ./traffic_monitor/experimental/traffic_monitor/manager/cacheavailablestatus.go
>   ./traffic_monitor/experimental/traffic_monitor/manager/datarequest.go
>   ./traffic_monitor/experimental/traffic_monitor/manager/dsstats.go
>   ./traffic_monitor/experimental/traffic_monitor/manager/events.go
>   ./traffic_monitor/experimental/traffic_monitor/manager/healthresult.go
>   ./traffic_monitor/experimental/traffic_monitor

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC4

[Dan Kirkwood]

Hi all.. We've decided to extend the voting until end-of-day
Monday,  December 19 to allow for more participation.If you have
voted on a previous RC,  please be sure to vote again.

The more information we get on what has been tried,  the better,   so
if you see problems or not,  please share!

Thanks..  Dan

On Tue, Dec 13, 2016 at 11:23 AM, Dan Kirkwood <dang...@gmail.com> wrote:
> I have no control over the mentors :-)Yes -- since you chimed in,
> I'm happy to wait for your input..
>
> -Dan
>
> On Tue, Dec 13, 2016 at 10:50 AM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>>> On Dec 13, 2016, at 7:47 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>>>
>>> So that makes us +1 overall,  since you're the only vote :-)
>>
>>
>> Eeep. Where are the mentor votes? :)
>>
>> I’m traveling and in meetings this week, but if you are extending the vote 
>> deadling, I can try to take a look tomorrow morning.
>>
>> Cheers,
>>
>> — leif
>>
>>>
>>> On Tue, Dec 13, 2016 at 8:45 AM, David Neuman <david.neuma...@gmail.com> 
>>> wrote:
>>>> A little late, but I am +1.
>>>>
>>>> On Mon, Dec 12, 2016 at 9:43 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>>>>>
>>>>> Reminder -- 1.8.0-RC4 is open for voting until 5pm MST today.   Please
>>>>> vote by replying to this email.  The release is available here:
>>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/
>>>>>
>>>>>
>>>>> On Thu, Dec 8, 2016 at 12:58 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>>>>> Hello All,
>>>>>>
>>>>>> I've prepared another release for v1.8.0 (RC4)
>>>>>>
>>>>>> Changes since 1.7.0:
>>>>>>
>>>>>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC4
>>>>>>
>>>>>> This corresponds to git:
>>>>>>  Hash: 7d8a88d0512ffe0354c2bc079ddbf2e7b67b6c3e
>>>>>>  Tag: RELEASE-1.8.0-RC4
>>>>>>
>>>>>> Which can be verified with the following:git tag -v
>>>>>> RELEASE-1.8.0-RC4
>>>>>>
>>>>>> My code signing key is available here:
>>>>>> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>>>>>>
>>>>>> Make sure you refresh from a key server to get all relevant signatures.
>>>>>>
>>>>>> Note that we are not providing the RPM files this time.   The only
>>>>>> artifact provided is a source tar file which can be downloaded from
>>>>>> here:
>>>>>>
>>>>>>
>>>>>> https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/
>>>>>>
>>>>>> Let me know if you need the rpm files and I can make arrangements to
>>>>>> get them to you.
>>>>>>
>>>>>> Per Apache guidelines, the .tar.gz file is signed with my pgp key (see
>>>>>> above) and md5 and sha1 checksums are also provided there.
>>>>>>
>>>>>> We'd like to shorten the turnaround time to around 3 days,  so this
>>>>>> vote is open until the end of the day Monday, December 12, 2016.
>>>>>>
>>>>>> Thanks!
>>>>
>>>>
>>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC4

[Dan Kirkwood]

Reminder -- 1.8.0-RC4 is open for voting until 5pm MST today.   Please
vote by replying to this email.  The release is available here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/


On Thu, Dec 8, 2016 at 12:58 PM, Dan Kirkwood <dang...@apache.org> wrote:
> Hello All,
>
> I've prepared another release for v1.8.0 (RC4)
>
> Changes since 1.7.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC4
>
> This corresponds to git:
>   Hash: 7d8a88d0512ffe0354c2bc079ddbf2e7b67b6c3e
>   Tag: RELEASE-1.8.0-RC4
>
> Which can be verified with the following:git tag -v RELEASE-1.8.0-RC4
>
> My code signing key is available here:
> http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex
>
> Make sure you refresh from a key server to get all relevant signatures.
>
> Note that we are not providing the RPM files this time.   The only
> artifact provided is a source tar file which can be downloaded from
> here:
>
>   https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/
>
> Let me know if you need the rpm files and I can make arrangements to
> get them to you.
>
> Per Apache guidelines, the .tar.gz file is signed with my pgp key (see
> above) and md5 and sha1 checksums are also provided there.
>
> We'd like to shorten the turnaround time to around 3 days,  so this
> vote is open until the end of the day Monday, December 12, 2016.
>
> Thanks!

[VOTE] Traffic Control RELEASE-1.8.0-RC4

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC4)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC4

This corresponds to git:
  Hash: 7d8a88d0512ffe0354c2bc079ddbf2e7b67b6c3e
  Tag: RELEASE-1.8.0-RC4

Which can be verified with the following:git tag -v RELEASE-1.8.0-RC4

My code signing key is available here:
http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

Note that we are not providing the RPM files this time.   The only
artifact provided is a source tar file which can be downloaded from
here:

  https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC4/

Let me know if you need the rpm files and I can make arrangements to
get them to you.

Per Apache guidelines, the .tar.gz file is signed with my pgp key (see
above) and md5 and sha1 checksums are also provided there.

We'd like to shorten the turnaround time to around 3 days,  so this
vote is open until the end of the day Monday, December 12, 2016.

Thanks!

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC3

[Dan Kirkwood]

+1 on that..   still working on getting release instructions updated,
but I think that's a superb idea...


On Thu, Dec 8, 2016 at 12:29 PM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> Any chance we could start running RAT as part of our CICD builds?
>
> I could probably set something up in our private Jenkins if theres not a 
> better option.
>
> —Eric
>
>> On Dec 8, 2016, at 11:24 AM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> FYI -- we decided to -1 this based on more license issues..   The
>> .rat-excludes file previously mentioned has been updated and those
>> issues resolved.   I'll be putting together a RC4 this morning.
>>
>> -Dan
>>
>> On Sat, Dec 3, 2016 at 4:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>>
>>>> On Dec 2, 2016, at 5:57 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>>>
>>>> Thanks again for the feedback,  Leif..There is a .rat_excludes
>>>> file at the top level,  but it looks like we didn't get it fully
>>>> populated.   The .json files should certainly be excluded..
>>>
>>> Oh, but it was not in the tar-ball, that’s why I couldn’t find it.
>>>
>>>>
>>>> According to the page you referred to earlier,  you can use one of
>>>> several methods to do create the md5 sum:
>>>> http://www.apache.org/dev/release-signing.html#md5 
>>>> <http://www.apache.org/dev/release-signing.html#md5> -- as we already
>>>> are using gpg for signing,  I figured that would be safe.. It
>>>> doesn't matter to me which we use,  but we should be consistent,   so
>>>> I'll document what we decide on in the release instructions..
>>>
>>> Yeh, I don’t care (much), as long as you are consistent (it should be part 
>>> of a build script / Makefile target).
>>>
>>> The ASCII armor validated fine btw :).
>>>
>>>>
>>>> Easy enough to include sha1 as well :-)
>>>
>>> Cool.
>>>
>>> Cheers,
>>>
>>> — leif
>>>
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC3

[Dan Kirkwood]

FYI -- we decided to -1 this based on more license issues..   The
.rat-excludes file previously mentioned has been updated and those
issues resolved.   I'll be putting together a RC4 this morning.

-Dan

On Sat, Dec 3, 2016 at 4:16 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Dec 2, 2016, at 5:57 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Thanks again for the feedback,  Leif..There is a .rat_excludes
>> file at the top level,  but it looks like we didn't get it fully
>> populated.   The .json files should certainly be excluded..
>
> Oh, but it was not in the tar-ball, that’s why I couldn’t find it.
>
>>
>> According to the page you referred to earlier,  you can use one of
>> several methods to do create the md5 sum:
>> http://www.apache.org/dev/release-signing.html#md5 
>> <http://www.apache.org/dev/release-signing.html#md5> -- as we already
>> are using gpg for signing,  I figured that would be safe.. It
>> doesn't matter to me which we use,  but we should be consistent,   so
>> I'll document what we decide on in the release instructions..
>
> Yeh, I don’t care (much), as long as you are consistent (it should be part of 
> a build script / Makefile target).
>
> The ASCII armor validated fine btw :).
>
>>
>> Easy enough to include sha1 as well :-)
>
> Cool.
>
> Cheers,
>
> — leif
>

Re: Apache license in source files

[Dan Kirkwood]

Hi Leif,

There's a .rat-excludes in the PR I posted today
(https://github.com/apache/incubator-trafficcontrol/pull/121) -- I'm
sure it's too liberal, but wanted to make sure we don't go backward..

-dan

On Mon, Dec 5, 2016 at 5:08 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Dec 5, 2016, at 3:48 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hi all.. We haven't really established a process for this,  but to
>> keep in compliance with Apache license guidelines,  each source file
>> should have the Apache license comment -- normally at the head of the
>> file, but I think that's somewhat flexible.
>>
>> Still going thru files adding them,  but when any new files get added,
>> they really should have that header in them already.
>>
>> What do you all think of establishing a guideline that any PR is not
>> merged until the license is present in each source file added?
>
>
> Very much +1. There are exceptions, at which point you would add them to the 
> RAT exclude file, but use that as sparingly as possible :).
>
> — Leif
>
>>
>> -dan
>

Re: Apache license in source files

[Dan Kirkwood]

Hey, Dave..  no finger pointing here..   We hadn't established any
guidelines yet,  so figured it was time to bring it up...

I had a PR myself yesterday that did the same thing...

We're getting there!!

-dan

On Mon, Dec 5, 2016 at 4:22 PM, David Neuman <david.neuma...@gmail.com> wrote:
> +1 and sorry for merging a PR without. I will make sure all files have them
> before merging in the future.
>
> On Mon, Dec 5, 2016 at 15:48 Dan Kirkwood <dang...@apache.org> wrote:
>
>> Hi all.. We haven't really established a process for this,  but to
>> keep in compliance with Apache license guidelines,  each source file
>> should have the Apache license comment -- normally at the head of the
>> file, but I think that's somewhat flexible.
>>
>> Still going thru files adding them,  but when any new files get added,
>> they really should have that header in them already.
>>
>> What do you all think of establishing a guideline that any PR is not
>> merged until the license is present in each source file added?
>>
>> -dan
>>

Apache license in source files

[Dan Kirkwood]

Hi all.. We haven't really established a process for this,  but to
keep in compliance with Apache license guidelines,  each source file
should have the Apache license comment -- normally at the head of the
file, but I think that's somewhat flexible.

Still going thru files adding them,  but when any new files get added,
they really should have that header in them already.

What do you all think of establishing a guideline that any PR is not
merged until the license is present in each source file added?

-dan

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC3

[Dan Kirkwood]

Thanks again for the feedback,  Leif..There is a .rat_excludes
file at the top level,  but it looks like we didn't get it fully
populated.   The .json files should certainly be excluded..

According to the page you referred to earlier,  you can use one of
several methods to do create the md5 sum:
http://www.apache.org/dev/release-signing.html#md5 -- as we already
are using gpg for signing,  I figured that would be safe.. It
doesn't matter to me which we use,  but we should be consistent,   so
I'll document what we decide on in the release instructions..

Easy enough to include sha1 as well :-)

We'll work on this more on Monday.

thanks! Dan



On Fri, Dec 2, 2016 at 4:07 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Dec 1, 2016, at 4:02 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hello All,
>>
>> I've prepared another release for v1.8.0 (RC3)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC3
>>
>> This corresponds to git:
>> Hash: daf585eacdcae4f57d60f14b4b6170b004058559
>> Tag: RELEASE-1.8.0-RC3
>>
>
>
> More nitpicking :).
>
> 1) Your .md5 is slightly unusual, pretty sure most ASF projects use a format 
> like
>
> fedora (15:44) 271/0 $ md5sum 
> incubator-trafficcontrol-1.8.0.4569.daf585ea.tar.gz
> d51294f20b2c19ab024cbb214740c498  
> incubator-trafficcontrol-1.8.0.4569.daf585ea.tar.gz
>
>
> 2) For shits and giggles, throw in the SHA1 sum too (it’s not required, but 
> suggested).
>
> 3) if it was me, I’d drop the commit ID :). I assume you are tagging the git 
> repo with the release version anyways, right ?
>
> 4) I’d much prefer if the tar-ball unpacked into e.g. 
> incubator-trafficcontrol-1.8.0-RC3 or some such.
>
> 5) There are still quite a lot of files lacking Apache License. See some 
> examples below. I can give a complete list if you need. Also, I couldn’t find 
> an exclude file to feed to the RAT app, that might also be something to 
> provide? There are legitimate cases where you can’t put a license into files, 
> such as the JSON files.
>
> 6) Continuing on 5), there’s a few things that looks like imports, but I 
> don’t see a blurb in NOTICE for ‘em. E.g.
>
> traffic_monitor/experimental/vendor/github.com/davecheney/gmx/ 
> <http://github.com/davecheney/gmx/>
> traffic_monitor/experimental/vendor/gopkg.in/fsnotify.v1
>
>
> I’m not 100% certain what the Incubator release policies are right now, but 
> I’d be surprised if they would not have a beef with the large amounts of 
> source files without license or attributions.
>
> Cheers,
>
> — leif
>
>   traffic_monitor/.classpath
>   traffic_monitor/.pmd
>   traffic_monitor/.project
>   traffic_monitor/README.md
>   traffic_monitor/pom.xml
>   traffic_monitor/build/pmd/ruleset.xml
>   traffic_monitor/etc/_astats
>   traffic_monitor/etc/_astats_static
>   traffic_monitor/etc/ats_sim.js
>   traffic_monitor/experimental/common/adapter/adapter.go
>   traffic_monitor/experimental/common/crstates/crstates.go
>   traffic_monitor/experimental/common/fetcher/fetcher.go
>   traffic_monitor/experimental/common/handler/handler.go
>   traffic_monitor/experimental/common/instrumentation/instrumentation.go
>   traffic_monitor/experimental/common/log/log.go
>   traffic_monitor/experimental/common/poller/poller.go
>   traffic_monitor/experimental/conf/traffic_ops.cfg
>   traffic_monitor/experimental/traffic_monitor/build.sh
>   traffic_monitor/experimental/traffic_monitor/index.html
>   traffic_monitor/experimental/traffic_monitor/sorttable.js
>   
> traffic_monitor/experimental/traffic_monitor/traffic_monitor-example-config.json
>   traffic_monitor/experimental/traffic_monitor/traffic_monitor.go
>   traffic_monitor/experimental/traffic_monitor/version.go
>   traffic_monitor/experimental/traffic_monitor/cache/astats.go
>   traffic_monitor/experimental/traffic_monitor/cache/astats.json
>   traffic_monitor/experimental/traffic_monitor/cache/astats_test.go
>   traffic_monitor/experimental/traffic_monitor/cache/cache.go
>   traffic_monitor/experimental/traffic_monitor/config/config.go
>   traffic_monitor/experimental/traffic_monitor/deliveryservice/stat.go
>   traffic_monitor/experimental/traffic_monitor/deliveryservicedata/stat.go
>   traffic_monitor/experimental/traffic_monitor/enum/enum.go
>   traffic_monitor/experimental/traffic_monitor/health/cache_health.go
>   traffic_monitor/experimental/traffic_monitor/manager/cacheavailablestatus.go
>   traffic_monitor/experimental/traffic_monitor/manager/datarequest.go
>   traffic_monitor/experimental/traffic_monitor/manager/dsstats.go
>   traffic_monitor/experimental/traffic_monit

[VOTE] Traffic Control RELEASE-1.8.0-RC3

[Dan Kirkwood]

Hello All,

I've prepared another release for v1.8.0 (RC3)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC3

This corresponds to git:
Hash: daf585eacdcae4f57d60f14b4b6170b004058559
Tag: RELEASE-1.8.0-RC3

Which can be verified with the following:

git tag -v RELEASE-1.8.0-RC3

My code signing key is available here:
  http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

Note that we are not providing the RPM files this time.   The only
artifact provided is a source tar file which can be downloaded from
here:
  https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC3/

Let me know if you need the rpm files and I can make arrangements to
get them to you.

Per Apache guidelines, the .tar.gz file is signed with my pgp key and
an md5 checksum is also provided there.

With this quick turnaround since the prior RC2,  I'd like to keep the
vote open until the same date:
The vote is open until Wednesday, December 7, 2016.

Thanks!

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC2

[Dan Kirkwood]

I'd also love to ditch the RPMs,but I'll abstain from voting since
it directly impacts me immediately (less work for me!).

Would anyone else like to weigh in on this?

Dan

On Thu, Dec 1, 2016 at 12:52 PM, Leif Hedstrom  wrote:
>
>> On Dec 1, 2016, at 12:46 PM, Phil Sorber  wrote:
>>
>> http://www.apache.org/dev/release-signing.html#basic-facts
>>
>> Missing checksums for the artifacts.
>>
>> And for the record, I am still not liking the RPM's as release artifacts,
>> but I'll let the IPMC weigh in on that.
>
>
> If I had a vote, now that you have the tar-ball, I’d ditch all he RPMs. If 
> someone needs the RPMs, make a Makefile target such that someone can produce 
> those source RPMs (shouldn’t they be .srpm) from the tar-ball.
>
> Cheers,
>
> — Leif
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC2

[Dan Kirkwood]

ahh..thanks,  Leif..I didn't realize it got the workspace in
there..That's a relic of our Jenkins CI build -- it clones into a
"workspace" dir.   Looks like I'll need to modify the build script to
be explicit when creating the tarball..

As for including the git hash in the file name,  we've been following
that convention in the rpm name for a while.   Do you think it should
be dropped from the tarball?   That's written to BUILD_NUMBER before
it's created..

-Dan

On Thu, Dec 1, 2016 at 12:35 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Nov 30, 2016, at 10:56 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>>
>> Hello All,
>>
>> I've prepared a release for v1.8.0 (RC2)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC2
>>
>> This corresponds to git:
>> Hash: 8766dbcb38105fbc97b955b4733defe40c83db00
>> Tag: RELEASE-1.8.0-RC2
>>
>> Which can be verified with the following:
>
>
> Minor (nit-pick) detail: Why does the tar-ball unpack into a directory named 
> “workspace”? I would have expected it to be 
> incubator-trafficcontrol-1.8.0.4567.8766dbcb .
>
> Also, why the UUID in the release name? Is that something the incubator wants 
> now?
>
> Cheers,
>
> — leif
>

[VOTE] Traffic Control RELEASE-1.8.0-RC2

[Dan Kirkwood]

Hello All,

I've prepared a release for v1.8.0 (RC2)

Changes since 1.7.0:
https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC2

This corresponds to git:
Hash: 8766dbcb38105fbc97b955b4733defe40c83db00
Tag: RELEASE-1.8.0-RC2

Which can be verified with the following:

git tag -v RELEASE-1.8.0-RC2

My code signing key is available here:
  http://keys.gnupg.net/pks/lookup?search=0x4587A8F0=vindex

Make sure you refresh from a key server to get all relevant signatures.

RPMs for all products are available here:
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC2/

The vote is open until Wednesday, December 7, 2016.

Thanks!

Re: Help the poor RMs

[Dan Kirkwood]

Still relevant tho..yes,  please help the poor RMs :-)

On Fri, Nov 11, 2016 at 2:54 PM, Leif Hedstrom  wrote:
>
>> On Nov 11, 2016, at 1:28 PM, David Neuman  wrote:
>>
>> I actually don't think we can do milestones, labels, or assignees in github
>> anymore. We lost that when we moved to the incubator github.  :(
>> But we should mark Jiras accordingly and open a Jira for a PR whenever it
>> makes sense.
>
>
>
> Gah, I sent this to the wrong mailing list … :-/
>
> Sorry,
>
> — leif
>

license details

[Dan Kirkwood]

Hi all,

I'm looking at files that are missing license details per Leif's email
from earlier today.   I'm finding that some aren't clear.   For
instance,  it appears that some files in
`docs/source/_themes/sphinx_rtd_theme` have a statement like this:

 >  :copyright: Copyright 2007-2013 by the Sphinx team, see AUTHORS.
 >  :license: BSD, see LICENSE for details.

but most others don't..  and there is no LICENSE or AUTHORS file
present with them.   Other instances of license issues include
/vendor/... directories in the traffic_ops/experimental area.I do
know the reason for those,  but assume I need to collect any copyright
info and post it in the NOTICE file.

Can anyone shed light on this info and/or is willing to help me ferret it out?

Thanks..  Dan

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[Dan Kirkwood]

ok -- tarball and  armored signatures are now included in
https://dist.apache.org/repos/dist/dev/incubator/trafficcontrol/1.8.0/RC1/
.   Adding that to the instructions for future release mgrs...

I'll work on getting the NOTICE updated and creating a KEYS file as
well.Once those are done,   we'll move on to RC2..

thanks!  Dan

On Wed, Nov 9, 2016 at 10:34 AM, Leif Hedstrom  wrote:
>
>> On Nov 8, 2016, at 6:46 PM, Eric Friedrich (efriedri)  
>> wrote:
>>
>> Hey Dan-
>>  I haven’t looked at the RPMs yet, but I think we also need to put up a 
>> package for astats.
>>
>> A few other things:
>>  - Package name should have “incubating” in it
>>  - Need signatures directly on the release packages (i.e. 1 detached sig per 
>> RPM/SRPM), see these:
>> https://www.apache.org/dev/release-publishing.html#valid
>> https://www.apache.org/dev/release-signing.html#basics 
>> 
>
> Yes, this is very important, you must have a GPG signature. Also, you should 
> make sure it’s easy / possible to get the public key of the person that 
> created these artifacts, ideally signed by other trusted people.
>
> See e.g. https://dist.apache.org/repos/dist/release/trafficserver/KEYS
>
> Cheers,
>
> — leif
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[Dan Kirkwood]

Thanks for looking at that,  Leif.. I'm sure we have a few more
details to get right..   I'm pretty sure most of those are from
external sources, so need to be added to NOTICE..

-Dan

On Wed, Nov 9, 2016 at 10:28 AM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Nov 8, 2016, at 3:27 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hello All,
>>
>> I've prepared a release for v1.8.0 (RC1)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1
>>  
>> <https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1>
>
> I ran RAT against the current git master, and it found a few potentially 
> missing licenses:
>
> http://pastebin.com/EQKZgSzT <http://pastebin.com/EQKZgSzT>
>
>
> I can’t (right now at least) easily test / verify the RPM source artifacts, 
> but if any of those files are in any of those RPMs / SRPMs, you might need to 
> update the license. The exception being files/packages where you’ve imported 
> from an external source, in which case they should be marked in the NOTICE 
> file (but, I don’t see any such entries, other than the primary contribution 
> notice from Comcast and Cisco).
>
> This is pretty important, it’d likely get a -1 from IPMC if you haven’t got 
> all this right :-).
>
> Cheers,
>
> — leif

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[Dan Kirkwood]

Thanks, Dave..   should the tarball include the git revision ids and
RC1 as well?

traffic_control_incubating-1.8.0-4549.bebf63ee-RC1.tar.gz

Dan

On Wed, Nov 9, 2016 at 10:14 AM, David Neuman <david.neuma...@gmail.com> wrote:
> I think we need to include a source tarball that contains the project name
> and "incubating" (e.g. traffic_control_incubating_1.8.0_source.tar.gz).
> We can also include the RPMs but we should note that they are for
> convenience only and therefore they shouldnt need incubating in the name.
>
> On Wed, Nov 9, 2016 at 9:13 AM, Dan Kirkwood <dang...@gmail.com> wrote:
>
>> Thanks,  Eric..
>>
>> I'll get the signatures in there, too and look into astats..
>> Suggestions on the form of the package name?  e.g.
>>
>> traffic_ops-incubator-1.8.0-RC1-..x86_64.rpm ?
>>
>> -dan
>>
>> On Tue, Nov 8, 2016 at 6:46 PM, Eric Friedrich (efriedri)
>> <efrie...@cisco.com> wrote:
>> > Hey Dan-
>> >   I haven’t looked at the RPMs yet, but I think we also need to put up a
>> package for astats.
>> >
>> > A few other things:
>> >   - Package name should have “incubating” in it
>> >   - Need signatures directly on the release packages (i.e. 1 detached
>> sig per RPM/SRPM), see these:
>> > https://www.apache.org/dev/release-publishing.html#valid
>> > https://www.apache.org/dev/release-signing.html#basics
>> >
>> >
>> > On Nov 8, 2016, at 5:38 PM, Dan Kirkwood <dang...@gmail.com<mailto:dang
>> o...@gmail.com>> wrote:
>> >
>> > Hi Leif,   we are aware of that and want to get to that point.   We've
>> > traditionally been Centos-based, and the rpm building is already
>> > implemented.  That's intended as a nicety to make testing the RC
>> > easier..   I, for one,  would love to eliminate building rpm's...
>> >
>> > Dan
>> >
>> > On Tue, Nov 8, 2016 at 3:32 PM, Leif Hedstrom <zw...@apache.org> zw...@apache.org>> wrote:
>> >
>> > On Nov 8, 2016, at 3:27 PM, Dan Kirkwood <dang...@apache.org<mailto:dan
>> g...@apache.org>> wrote:
>> >
>> > Hello All,
>> >
>> > I've prepared a release for v1.8.0 (RC1)
>> >
>> > Changes since 1.7.0:
>> > https://github.com/apache/incubator-trafficcontrol/
>> compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1
>> >
>> > This corresponds to git:
>> > Hash: bebf63eedce2d3912752c65b0d52d739f820e0ac
>> > Tag: RELEASE-1.8.0-RC1
>> >
>> >
>> > Hmmm, quick question: Why RPMs? That seems pretty restrictive, in that
>> someone could not download / test / look at any of this without having an
>> OS distro that supports RPM… It’d be preferable (IMO at least) to have
>> source artifacts as regular tar-balls (gzip / bzip2’d).
>> >
>> > Cheers,
>> >
>> > — Leif
>> >
>> >
>>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[Dan Kirkwood]

Thanks,  Eric..

I'll get the signatures in there, too and look into astats..
Suggestions on the form of the package name?  e.g.

traffic_ops-incubator-1.8.0-RC1-..x86_64.rpm ?

-dan

On Tue, Nov 8, 2016 at 6:46 PM, Eric Friedrich (efriedri)
<efrie...@cisco.com> wrote:
> Hey Dan-
>   I haven’t looked at the RPMs yet, but I think we also need to put up a 
> package for astats.
>
> A few other things:
>   - Package name should have “incubating” in it
>   - Need signatures directly on the release packages (i.e. 1 detached sig per 
> RPM/SRPM), see these:
> https://www.apache.org/dev/release-publishing.html#valid
> https://www.apache.org/dev/release-signing.html#basics
>
>
> On Nov 8, 2016, at 5:38 PM, Dan Kirkwood 
> <dang...@gmail.com<mailto:dang...@gmail.com>> wrote:
>
> Hi Leif,   we are aware of that and want to get to that point.   We've
> traditionally been Centos-based, and the rpm building is already
> implemented.  That's intended as a nicety to make testing the RC
> easier..   I, for one,  would love to eliminate building rpm's...
>
> Dan
>
> On Tue, Nov 8, 2016 at 3:32 PM, Leif Hedstrom 
> <zw...@apache.org<mailto:zw...@apache.org>> wrote:
>
> On Nov 8, 2016, at 3:27 PM, Dan Kirkwood 
> <dang...@apache.org<mailto:dang...@apache.org>> wrote:
>
> Hello All,
>
> I've prepared a release for v1.8.0 (RC1)
>
> Changes since 1.7.0:
> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1
>
> This corresponds to git:
> Hash: bebf63eedce2d3912752c65b0d52d739f820e0ac
> Tag: RELEASE-1.8.0-RC1
>
>
> Hmmm, quick question: Why RPMs? That seems pretty restrictive, in that 
> someone could not download / test / look at any of this without having an OS 
> distro that supports RPM… It’d be preferable (IMO at least) to have source 
> artifacts as regular tar-balls (gzip / bzip2’d).
>
> Cheers,
>
> — Leif
>
>

Re: [VOTE] Traffic Control RELEASE-1.8.0-RC1

[Dan Kirkwood]

Hi Leif,   we are aware of that and want to get to that point.   We've
traditionally been Centos-based, and the rpm building is already
implemented.  That's intended as a nicety to make testing the RC
easier..   I, for one,  would love to eliminate building rpm's...

Dan

On Tue, Nov 8, 2016 at 3:32 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>> On Nov 8, 2016, at 3:27 PM, Dan Kirkwood <dang...@apache.org> wrote:
>>
>> Hello All,
>>
>> I've prepared a release for v1.8.0 (RC1)
>>
>> Changes since 1.7.0:
>> https://github.com/apache/incubator-trafficcontrol/compare/RELEASE-1.7.0...RELEASE-1.8.0-RC1
>>
>> This corresponds to git:
>> Hash: bebf63eedce2d3912752c65b0d52d739f820e0ac
>> Tag: RELEASE-1.8.0-RC1
>
>
> Hmmm, quick question: Why RPMs? That seems pretty restrictive, in that 
> someone could not download / test / look at any of this without having an OS 
> distro that supports RPM… It’d be preferable (IMO at least) to have source 
> artifacts as regular tar-balls (gzip / bzip2’d).
>
> Cheers,
>
> — Leif
>

Re: incubator-trafficcontrol

[Dan Kirkwood]

Hi Burak,

The best place to ask questions is one of the mailing lists -- for using
traffic control, you can subscribe at  users-subscribe@trafficcont
rol.incubator.apache.org,
and for development: dev-subscr...@trafficcontrol.incubator.apache.org.

We have been working on adding docker containers for each component,  but
that work is not yet finished.   For now, it's best to follow the
instructions on http://traffic-control-cdn.net/ and ask questions on the
mailing list for setting up the servers.

We will watch for your questions on the mailing list.

Thanks!Dan

On Fri, Oct 21, 2016 at 12:40 AM, Burak Sarp  wrote:

> hi dangogh,
>
> i am trying to contribute something to incubator-trafficcontrol, but i can
> not up servers,
> I am using docker compose, i think docker compose builds the projects bot
> for up servers,
> Could you help me to up traffic control?
>
> thanks,
> -burak
>