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

[Leif Hedstrom]

> On Apr 2, 2018, at 2:11 PM, David Neuman  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)
> 


+1 (binding)

— Leif

Re: [VOTE] Traffic Control graduation to TLP

[Leif Hedstrom]

+1

— Leif 

> On Mar 1, 2018, at 08:41, Dave Neuman  wrote:
> 
> Hey All,
> 
> After a great discussion amongst the Apache Traffic Control PPMC, reviewing
> the graduation checklist[1], updating the podling status page[2], and
> updating the project website to ensure the whimsy podling website checks
> pass[3], I would like to call a vote for Apache Traffic Control graduating
> to a top level project.
> 
> Apache Traffic Control entered the incubator on July 12, 2016.  Since then
> we have announced 4 releases, nominated 4 new committers, organized 3
> summits, had almost 8,000 commits from 63 different contributors, and --
> most importantly -- we have grown and diversified our community.  Apache
> Traffic Control is a healthy project that is already acting like an Apache
> top level project, so we should take the next step.
> 
> If we agree that we should graduate to a top level project, the next steps
> will be to pick the initial PMC chair for the TLP and draft a Resolution
> for the PPMC and IPMC to vote upon.
> 
> Please take a minute to vote on wheter or not Traffic Control should
> graduate to a Top Level Project by responding with one of the following:
> 
> [ ] +1 Apache Traffic Control should graduate.
> [ ] +0 No opinion
> [ ] -1 Apache Traffic Control should not graduate (please provide the
> reason)
> 
> The VOTE will be opened for at least the next 72 hours.  Per Apache
> guidelines[4] I will also be notifying the incubator mailing list that a
> community vote is under way.
> 
> Thanks,
> Dave
> 
> 
> [1]
> https://incubator.apache.org/guides/graduation.html#graduation_check_list
> [2] http://incubator.apache.org/projects/trafficcontrol.html
> [3] https://whimsy.apache.org/pods/project/trafficcontrol
> [4]
> https://incubator.apache.org/guides/graduation.html#community_graduation_vote

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

[Leif Hedstrom]

> On Jan 9, 2018, at 10:22 AM, 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:
> 
> [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
> 


To add to the previous thread / thoughts. I feel reasonably strongly that 
having a changelog label in Github is not useful. In the ATS community, we can 
*barely* get people to set the Milestone properly, and I feel that the 
Milestone is a much more important thing to keep accurate than anything else. 
And, to be normalized, you don’t want to duplicate this info :-).

So, what we do is have the RM be like a hawk over the Milestones, and then run 
Phil’s fancy pants script to generate the ChangeLog from the Milestones on all 
PRs closed.

Cheers,

— leif

> 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 haven't seen anyone state why they don't like what Steve has
>>> proposed?  I
 think what he is proposing is pretty standard across major Github
>>> projects
 that I have seen.  I understand that we can introduce some additional
 inconvenience with having to manually write what your feature or bug
>> fix
 does, and there could be some conflicts, but isn't it important to
>>> clearly
 portray what has changed?  I don't think we need a changelog.md entry
>> to
 every PR, in fact I hope we don't...we need a changelog.md entry any
>>> time
 we add a new feature, any time we have some operational considerations
>>> that
 need to be communicated, or any time that we fix a bug from a previous
 release.
 
 
 On Thu, Dec 14, 2017 at 2:02 PM, Jeremy Mitchell <
>> mitchell...@gmail.com>
 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 

Re: Traffic Control with ATS 7+

[Leif Hedstrom]

> On Nov 21, 2017, at 9:45 PM, Mark Torluemke  wrote:
> 
> I agree -- supporting 3 ATS major versions is likely more work than it's
> worth. Traffic Ops core should continue to move towards being cache
> software agnostic.
> 
> Having said that, we have some logic today that generates config files
> differently, based on the ATS major version:


Agreed. And remember that ATS 5.x is no longer a supported version. You really 
should encourage users *not* to use a version of ATS that will no longer see 
any updates :-).

— leif

Re: [VOTE] Bugtracking in Github Issues

[Leif Hedstrom]

> On Aug 29, 2017, at 4:47 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 
> 
>> On Aug 28, 2017, at 10:38 AM, Eric Friedrich (efriedri) <efrie...@cisco.com> 
>> 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. 
> 
> 
> 
> I’m +1 on this, but did you verify with the Incubator powers that this is 
> allowed? Another option is to defer this until you are down with incubation, 
> and make the migration to a TLP include moving more of your workflow over to 
> Github proper.



I also should point out that Github Issues is vastly inferior to Jira, in every 
aspect other than that more people know and are used to the shitty Github 
system :-).

Cheers,

— Leif

Re: [VOTE] Bugtracking in Github Issues

[Leif Hedstrom]

> On 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. 



I’m +1 on this, but did you verify with the Incubator powers that this is 
allowed? Another option is to defer this until you are down with incubation, 
and make the migration to a TLP include moving more of your workflow over to 
Github proper.

— Leif

Re: Public CI Builds for Traffic Control

[Leif Hedstrom]

> On Mar 14, 2017, at 6:15 PM, Chris Lemmons <alfic...@gmail.com> wrote:
> 
> Honestly, the key is hosting. If we have a host for CI that runs the basic
> build steps, we can configure any solution to build all the changes on
> branches of a collection of repos on Github. Pretty much all the reasonable
> options have a status update script on GitHub, which integrates it quite
> nicely. (And therein might lie the rub. I think GitHub ties status updates
> to "push permission", which may be false for everyone on the main repo,
> since it's just a mirror.) But direct integration or no, we'd be able to go
> look at the results and even download the binary, install it on a test
> system and watch it go.


So, we do not have the Jenkins master have “write permission” into the Github 
repo. I asked Infra before, and they said no, but I’ll try again.

However, things can still work reasonably well, since any registered Github 
accounts is able to comment on a PR / issue. So, no, we can’t set labels etc. 
automatically from the Jenkins master, but we get pretty good feedback on what 
happens with the builds. See e.g.

https://github.com/apache/trafficserver/pull/1581 
<https://github.com/apache/trafficserver/pull/1581>


Cheers,

— leif

> 
> Now, that doesn't get us automatic builds from first-time or probably even
> very occasional contributors. But stick builds on the most frequent
> contributors' clones and we get 95% of the benefit without solving any of
> the actually hard problems.
> 
> We'd need a host, though.
> 
> On Tue, Mar 14, 2017 at 5:06 PM Leif Hedstrom <zw...@apache.org> wrote:
> 
>> 
>>> On Mar 13, 2017, at 8:44 AM, Chris Lemmons <alfic...@gmail.com> wrote:
>>> 
>>> To me, the key features of CI are that a) it builds each branch
>>> automatically, b) notifies affected parties when all is not well, and c)
>>> manages the artefacts in a reasonable way. Additionally, we're a lot more
>>> useful when we're writing neat software and not spending out time
>> managing
>>> CI, so it should be as automatic as reasonable. We're using github for
>> PRs,
>>> so if it's at all possible to get automatic PR tagging with build
>>> information, that is greatly desirable. Knowing that the PR breaks the
>>> build prior to merging it can save quite a bit of time. :)
>> 
>> 
>> My $0.25: My experience is that making as much CI build / tests on pull
>> requests, *before* they are landed, gives the most bang for the buck. But
>> that might not work well for you, since you can’t use Github right?
>> 
>> — leif
>> 
>>> 
>>> I've not used BuildBot, but it feels... svney?
>>> 
>>> Jenkins can do all of the above, though basically all those features are
>>> plugins. There's a "build per branch" plugin that uses branches to
>>> automatically make builds. There's a variety of notifier plugins. There
>> are
>>> some artefact management plugins. There is a "build PRs" plugin that's
>>> specifically designed for GitHub. Jenkins isn't much on its own, but
>>> properly adorned with plugins, it can do most of what we'd want, I think.
>>> 
>>> I've also had extensive experience with Bamboo, Atlassian's closed-source
>>> solution in the same suite as Jira. Bamboo is usable gratis for OSS in
>> the
>>> same way we currently use Apache Jira.
>>> 
>>> Bamboo also has plugins, but the majority of it's features are good to go
>>> immediately. There's an automatic checkbox for "build per branch". The
>>> artefacts are managed fairly automatically, especially if you fill in the
>>> "build expiration" boxes. Notification is automatic and easy to
>> configure.
>>> It's got a (free) plugin for PR statuses.
>>> 
>>> In any case, we'll need to manually configure the valid lists of
>>> contributors. For security reasons, we probably can't just run whatever
>> PR
>>> is created without any prior contact. :/ In Jenkins, this looks like
>>> maintaining a "white list" of legal contributors for a PR inside the PR
>>> plugin. In Bamboo, it looks like listing the committer forks as copied
>>> projects. Either way is fairly manageable.
>>> 
>>> Jenkins and Bamboo both run on Java. So... no winner there. :)
>>> 
>>> I think the major question is one of hosting. No matter what solution we
>>> use, we need a few cycles, a network interface, and a bit of disk space
>> to
>>> run it. The apache jenkins appears to have almost all the st

Re: Public CI Builds for Traffic Control

[Leif Hedstrom]

> On Mar 13, 2017, at 8:44 AM, Chris Lemmons  wrote:
> 
> To me, the key features of CI are that a) it builds each branch
> automatically, b) notifies affected parties when all is not well, and c)
> manages the artefacts in a reasonable way. Additionally, we're a lot more
> useful when we're writing neat software and not spending out time managing
> CI, so it should be as automatic as reasonable. We're using github for PRs,
> so if it's at all possible to get automatic PR tagging with build
> information, that is greatly desirable. Knowing that the PR breaks the
> build prior to merging it can save quite a bit of time. :)


My $0.25: My experience is that making as much CI build / tests on pull 
requests, *before* they are landed, gives the most bang for the buck. But that 
might not work well for you, since you can’t use Github right?

— leif

> 
> I've not used BuildBot, but it feels... svney?
> 
> Jenkins can do all of the above, though basically all those features are
> plugins. There's a "build per branch" plugin that uses branches to
> automatically make builds. There's a variety of notifier plugins. There are
> some artefact management plugins. There is a "build PRs" plugin that's
> specifically designed for GitHub. Jenkins isn't much on its own, but
> properly adorned with plugins, it can do most of what we'd want, I think.
> 
> I've also had extensive experience with Bamboo, Atlassian's closed-source
> solution in the same suite as Jira. Bamboo is usable gratis for OSS in the
> same way we currently use Apache Jira.
> 
> Bamboo also has plugins, but the majority of it's features are good to go
> immediately. There's an automatic checkbox for "build per branch". The
> artefacts are managed fairly automatically, especially if you fill in the
> "build expiration" boxes. Notification is automatic and easy to configure.
> It's got a (free) plugin for PR statuses.
> 
> In any case, we'll need to manually configure the valid lists of
> contributors. For security reasons, we probably can't just run whatever PR
> is created without any prior contact. :/ In Jenkins, this looks like
> maintaining a "white list" of legal contributors for a PR inside the PR
> plugin. In Bamboo, it looks like listing the committer forks as copied
> projects. Either way is fairly manageable.
> 
> Jenkins and Bamboo both run on Java. So... no winner there. :)
> 
> I think the major question is one of hosting. No matter what solution we
> use, we need a few cycles, a network interface, and a bit of disk space to
> run it. The apache jenkins appears to have almost all the stuff we need. It
> does not appear to have docker-compose, which we're leveraging fairly
> significantly at the moment. docker-compose, however, is Apache licensed,
> so we could theoretically ship it inside the repo. Not sure I like that
> option, though. We could also switch off of compose and put the relevant
> options into our build script directly. Not sure I like that option, either.
> 
> We'd have the most flexibility if we could get one or more companies to
> donate a publicly accessible host (or even theoretically, a build slave),
> assuming that doesn't break Apache's rules. The CI doesn't need a ton of
> gas, but the more oomph it has, the more granularly it can build and more
> aggressively we can test.
> 
> On Sun, Mar 12, 2017 at 6:54 PM Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> 
> Hey All-
>  I’d played around before with Travis CI for Continuous Integration
> builds, but never actually set it up for the public repo.
> 
> I know some others on the list have tried out comparable services. Does
> anyone have experience or suggestions to share?
> 
> Also, we can now get access to Apache Buildbot (
> https://ci.apache.org/buildbot.html) and an Apache hosted Jenkins (
> https://cwiki.apache.org/confluence/display/INFRA/Jenkins)
> 
> I think Traffic Server has their own separate Jenkins server so they can
> hit more platforms, but with the latest build changes, pretty much all we
> require is access to a docker daemon
> 
> —Eric

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

[Leif Hedstrom]

> On Feb 21, 2017, at 9:06 AM, Dan Kirkwood  wrote:
> 
> Hello Incubator PMC,
> 

+1 (binding)

— Leif

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

[Leif Hedstrom]

> On Feb 16, 2017, at 12:39 PM, Dan Kirkwood  wrote:
> 
> We have 4 +1 already,   so I'm declaring RC10 as passed!


Fwiw, that’s not generally how things work. You had stated that the vote was 
very short (“end of the day”), so at a minimum you need to let that time pass. 
The reason for this is because you need to give people time to -1 a vote, i.e. 
it’s not sufficient to just have achieved 3 or more +1 votes.

Moot point since you -1 it yourself, but this is an important step of the 
voting process. I’d personally not do anything less than 24h on a vote, and 
more common is at least 72h.

Cheers,

— leif

> 
> I'll send out the email to the IPMC shortly...
> 
> Thanks all..
> 
> -dan
> 
> On Thu, Feb 16, 2017 at 11:50 AM, Dan Kirkwood  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: clang-analyzer on the CI

[Leif Hedstrom]

> On Feb 1, 2017, at 3:21 PM, Leif Hedstrom <zw...@apache.org> wrote:
> 
> Hi all,
> 
> I’ve enabled the Clang analyzer builds for the CI. I’d highly recommend that 
> if it fails, you look into why, at least for PRs on master. Unfortunately, I 
> haven’t figured out a good way to expose the actual details in some 
> meaningful way, I’m still working on that. In the mean time, if a 
> clang-analyzer build fails, you can ask me for details as to why.
> 
> Cheers,


Sigh, wrong dev list, obviously …

Sorry.

— Leif

clang-analyzer on the CI

[Leif Hedstrom]

Hi all,

I’ve enabled the Clang analyzer builds for the CI. I’d highly recommend that if 
it fails, you look into why, at least for PRs on master. Unfortunately, I 
haven’t figured out a good way to expose the actual details in some meaningful 
way, I’m still working on that. In the mean time, if a clang-analyzer build 
fails, you can ask me for details as to why.

Cheers,

-- leif

P.s
Long story short, the reports come in an HTML format, so ideally I’d be able to 
pack them up and make them available via the Jenkins build page...

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

[Leif Hedstrom]

> On Jan 27, 2017, at 9:46 AM, Dan Kirkwood  wrote:
> 
> +1
> 
> -- was assuming as release manager I didn't get a vote,  but not true?

Everyone gets to vote :). If you are a PPMC member, your vote is binding. We 
should encourage non-PPMC members to vote as well, some of the best problem 
reports tend to come from those who did not actively work on the code.

Fwiw, being the RM is not “special”, you are in theory just packaging up all 
the work the community has put together.  Excluding the RM from voting seems 
unfair :).

Cheers,

— Leif


> 
> 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  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!

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

[Leif Hedstrom]

> On Jan 6, 2017, at 2:15 PM, Dan Kirkwood  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
>  
> 

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

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

[Leif Hedstrom]

> On Dec 13, 2016, at 7:47 AM, Dan Kirkwood  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  
> wrote:
>> A little late, but I am +1.
>> 
>> On Mon, Dec 12, 2016 at 9:43 AM, Dan Kirkwood  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  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-RC3

[Leif Hedstrom]

> On Dec 8, 2016, at 12:29 PM, Eric Friedrich (efriedri)  
> 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. 


+1 as well.

Fwiw, we do this nightly on the ATS CI:

https://ci.trafficserver.apache.org/view/nightly/ 



— Leif

Re: Apache license in source files

[Leif Hedstrom]

> On Dec 5, 2016, at 3:48 PM, Dan Kirkwood  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: [VOTE] Traffic Control RELEASE-1.8.0-RC3

[Leif Hedstrom]

> On Dec 2, 2016, at 5:57 PM, Dan Kirkwood  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 
>  -- 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

[Leif Hedstrom]

> On Dec 1, 2016, at 4:02 PM, Dan Kirkwood  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/ 

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_monitor/manager/events.go
  traffic_monitor/experimental/traffic_monitor/manager/healthresult.go
  traffic_monitor/experimental/traffic_monitor/manager/lastkbpsstats.go
  traffic_monitor/experimental/traffic_monitor/manager/manager.go
  traffic_monitor/experimental/traffic_monitor/manager/monitorconfig.go
  traffic_monitor/experimental/traffic_monitor/manager/opsconfig.go
  traffic_monitor/experimental/traffic_monitor/manager/peer.go
  traffic_monitor/experimental/traffic_monitor/manager/polledcaches.go
  traffic_monitor/experimental/traffic_monitor/manager/stathistory.go
  traffic_monitor/experimental/traffic_monitor/manager/uintman.go
  traffic_monitor/experimental/traffic_monitor/peer/crstates.go
  traffic_monitor/experimental/traffic_monitor/peer/crstates.json
  traffic_monitor/experimental/traffic_monitor/peer/peer.go
  traffic_monitor/experimental/traffic_monitor/peer/peer_test.go
  traffic_monitor/experimental/traffic_monitor/srvhttp/srvhttp.go
  traffic_monitor/experimental/traffic_monitor/trafficopsdata/trafficopsdata.go
  
traffic_monitor/experimental/traffic_monitor/trafficopswrapper/trafficopswrapper.go
  
traffic_monitor/src/main/java/com/comcast/cdn/traffic_control/traffic_monitor/Index.html
  

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

[Leif Hedstrom]

> 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: Help the poor RMs

[Leif Hedstrom]

> 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

Help the poor RMs

[Leif Hedstrom]

Please make an effort to mark GitHub PRs (and Jiras) with relevant information. 
In Github, you have Milestones (versions), Labels (components etc.) as well as 
assignee you can use. You can also add PRs to the projects, to help with back 
ports etc.

Same with Jira, at a minimum add the appropriate version information, 
Components etc.

Don’t expect someone else will do this for you  :-).

— leif

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

[Leif Hedstrom]

> 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

[Leif Hedstrom]

> On Nov 8, 2016, at 3:27 PM, Dan Kirkwood  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
>  
> 

I ran RAT against the current git master, and it found a few potentially 
missing licenses:

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

[Leif Hedstrom]

> On Nov 8, 2016, at 3:27 PM, Dan Kirkwood  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