Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Dean Troyer
On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) 
kevin...@cisco.com wrote:

 ATC is only being given to folks committing to the current branch (
 https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/
 ).



 Secondly, it's difficult to get stack-analytics credit for back ports, as
 the preferred method is to cherry pick the code, and that keeps the
 original author's name.



 My fear is that we're going in a direction where trunk is the sole focus
 and we're subsequently going to lose the support of the majority of the
 operators and enterprises at which point we'll be a fun research project,
 but little more.


[I've cherry-picked above what I think are the main points here... not
directed at you Kevin.]


This is not Somebody Else's Problem.

Stable maintenance is Not Much Fun, no question.  Those who have demanded
the loudest that we (the development community) maintain these stable
branches need to be the one supporting it the most. (I have no idea how
that matches up today, so I'm not pointing out anyone in particular.)

* ATC credit should be given, stable branch maintenance is a contribution
to the project, no question.

* I have a bit of a problem with stack-analytics being an issue partially
because that is not what should be driving corporate contributions and
resource allocation.  But it does.  Relying on a system with known
anomalies like the cherry-pick problem gets imperfect results.

* The vast majority of the OpenStack contributors are paid to do their work
by a (most likely) Foundation member company.  These companies choose how
to allocate their resources, some do quite well at scratching their
particular itches, some just make a lot of noise.  If fun is what drives
them to select where they apply resources, then they will reap what they
sow.

The voice of operators/users/deployers in this conversation should be
reflected through the entity that they are paying to provide operational
cloud services.  It's those directly consuming the code from openstack.org
that are responsible here because they are the ones directly making money
by either providing public/private cloud services, or reselling a
productized OpenStack or providing consulting services and the like.

This should not stop users/operators from contributing information,
requirements or code in any way.  But if they have to go around their
vendor then that vendor has failed them.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Jeremy Stanley
On 2015-02-10 15:20:46 + (+), Kevin Bringard (kevinbri) wrote:
[...]
 I've been talking with a few people about this very thing lately,
 and I think much of it is caused by what appears to be our
 actively discouraging people from working on it. Most notably, ATC
 is only being given to folks committing to the current branch
 (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/).

The comments on that answer are somewhat misleading, so I'll follow
up there as well to set the record straight. The script[1] which
identifies ATCs for the purpose of technical elections and summit
passes is based entirely on Gerrit owners (uploaders) of changes
merged to official projects within a particular time period. It
doesn't treat master differently from any other branches. People who
do the work to upload backports to stable branches absolutely do get
counted for this purpose. People who only review changes uploaded by
others do not (unless they are manually added to the extra-atcs
file in the openstack/governance repo), but that is the case for all
branches including master so not something stable-branch specific.

Though I *personally* hope that is not the driving force to convince
people to work on stable support. If it is, then we've already lost
on this front.

 Secondly, it's difficult to get stack-analytics credit for back
 ports, as the preferred method is to cherry pick the code, and
 that keeps the original author's name. I've personally gotten a
 few commits into stable, but have nothing to show for it in
 stack-analytics (if I'm doing it wrong, I'm happy to be
 corrected).
[...]

Stackalytics isn't an official OpenStack project, but you should
file a bug[2] against it if there's a feature you want its authors
to consider adding.

[1] 
https://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/atc/email_stats.py
[2] https://bugs.launchpad.net/stackalytics/+filebug
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]

2015-02-10 Thread Mark Voelker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The voice of operators/users/deployers in this conversation should be reflected 
through the entity that they are paying to provide operational cloud services.  

Let’s be careful here: I hope you didn’t mean to say that 
operators/users/deployers voices should only be heard when they pay a vendor to 
get OpenStack (and I don’t think you did, but it read that way a bit).  

It's those directly consuming the code from openstack.org that are responsible 
here because they are the ones directly making money by either providing 
public/private cloud services, or reselling a productized OpenStack or 
providing consulting services and the like.

Sure, I agree those folks certainly have an interest...but I don’t believe it’s 
solely their responsibility and that the development community has none.  If 
the development community has no responsibility for maintaining stable code, 
why have stable branches at all?  If we aren’t incentivizing contributions to 
stable code, we’re encouraging forking, IMHO.  There’s a balance to be struck 
here.  I think what’s being voiced in this thread is that we haven’t gotten to 
that place yet where there are good incentives to contribute to stable branch 
(not just back porting fixes, but dealing with gate problems, etc as well) and 
we’d like to figure out how to improve that situation.

At Your Service,

Mark T. Voelker
OpenStack Architect

On Feb 10, 2015, at 11:21 AM, Dean Troyer dtro...@gmail.com wrote:

On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) kevin...@cisco.com 
wrote:
ATC is only being given to folks committing to the current branch 
(https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/).
 
Secondly, it's difficult to get stack-analytics credit for back ports, as the 
preferred method is to cherry pick the code, and that keeps the original 
author's name.
 
My fear is that we're going in a direction where trunk is the sole focus and 
we're subsequently going to lose the support of the majority of the operators 
and enterprises at which point we'll be a fun research project, but little more.

[I've cherry-picked above what I think are the main points here... not directed 
at you Kevin.]


This is not Somebody Else's Problem.

Stable maintenance is Not Much Fun, no question.  Those who have demanded the 
loudest that we (the development community) maintain these stable branches need 
to be the one supporting it the most. (I have no idea how that matches up 
today, so I'm not pointing out anyone in particular.) 

* ATC credit should be given, stable branch maintenance is a contribution to 
the project, no question.

* I have a bit of a problem with stack-analytics being an issue partially 
because that is not what should be driving corporate contributions and resource 
allocation.  But it does.  Relying on a system with known anomalies like the 
cherry-pick problem gets imperfect results.

* The vast majority of the OpenStack contributors are paid to do their work by 
a (most likely) Foundation member company.  These companies choose how to 
allocate their resources, some do quite well at scratching their particular 
itches, some just make a lot of noise.  If fun is what drives them to select 
where they apply resources, then they will reap what they sow.

The voice of operators/users/deployers in this conversation should be reflected 
through the entity that they are paying to provide operational cloud services.  
It's those directly consuming the code from openstack.org that are responsible 
here because they are the ones directly making money by either providing 
public/private cloud services, or reselling a productized OpenStack or 
providing consulting services and the like.

This should not stop users/operators from contributing information, 
requirements or code in any way.  But if they have to go around their vendor 
then that vendor has failed them.

dt

- -- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU2kAYAAoJELUJLUWGN7CbJpEQAJJmw/RlgRMxVSyuWZpcvJmn
nWVLw3KJTspGz5V9clFG6QYgDR5ygWNz51e+QT0Ps+baOWxq9Figwur2yyYfOt8c
hissfjL+OPG2QRrAQOwys7n2s5bSb28ePvO+/benY1PykAknpZX4lq28V4gfqRX9
+2ZjxNs+orkj0cuDi1KdhZPjfo1fuZ07GgCjFy1Xuqq7rYBLfrkEffmF2dbxF67R
aHxbTWe9CgX6IlTL1p5rH7wCKyYQrkFUEXXG3w3CpdWJQ4Ky2bvC/JyKX8wFOkqp
AL7voCvG0zwPV+BHBVabqobC7qb+7+uYd6IQRovuxVxcl9ZdI0o9GQyhcXf890IQ
Sq8Z+PApzOvd8pxQdpq0SBYlVZUsjuBe3YGfvmHg/3hyto+FUzKhJOfjfLepST5U
tThEQzSnfZwfgnTkI3/rN9zMvlg7vsP15lRJzRx+ycQhyzTJZdlEiA+yIQF3tdrZ
h1ZW1M4Dc9R/R56jRV3YeSxY1wMUlBHm4Gn+uKVS3q/dKjIOkYjJEEDVcDd/wCYh
Uknp5GFsZi6Uvj0Dgymllrk7HCustzEhog4r0mORH6W0HtYVK0U/NvaRFXkF/VS0

Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Jeremy Stanley
On 2015-02-10 10:21:58 -0600 (-0600), Dean Troyer wrote:
[...]
 ATC credit should be given, stable branch maintenance is a
 contribution to the project, no question.
[...]

Just to keep this particular misconception from spinning out of
control, as I mentioned elsewhere in this thread they absolutely
already do. Stable branch changes are treated no differently from
any other Gerrit changes in this regard.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]

2015-02-10 Thread Stefano Maffulli
On Tue, 2015-02-10 at 15:20 +, Kevin Bringard (kevinbri) wrote:
 I've been talking with a few people about this very thing lately, and
 I think much of it is caused by what appears to be our actively
 discouraging people from working on it. Most notably, ATC is only
 being given to folks committing to the current branch
 (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/).

As Jeremy clarified, this is wrong. I edited the answer to be even more
explicit.

  Secondly, it's difficult to get stack-analytics credit for back
 ports, as the preferred method is to cherry pick the code, and that
 keeps the original author's name. I've personally gotten a few commits
 into stable, but have nothing to show for it in stack-analytics (if
 I'm doing it wrong, I'm happy to be corrected)

First I want to clarify that git history on
http://activity.openstack.org visualizes commits (merged changes, more
properly) to all branches, not just trunk.

That said, we probably still miss some attribution there because we
count committers only by looking at the author of a change. If
backports are cherry-picked and therefore retain the author then the new
owner is not *counted* as a new contributor.

I highlight that the scope of Activity Board is not to create vanity
charts but only to highlight trends that are useful to understand the
health of the community. It never had any intention to be precise
because 100% precision is hard.

That said, I'm adding the metrics tag because if there is a way to add
owners of back-ports to the count of contributors to OpenStack that'd be
good.

And if we want to improve the number of contributors to stable release,
we may even create a new panel to show such trend.  Do you agree we need
to look in detail, separately to contributors to stable and to trunk
instead of one blob?

/stef


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Ilya Shakhat

  Secondly, it's difficult to get stack-analytics credit for back
  ports, as the preferred method is to cherry pick the code, and
  that keeps the original author's name. I've personally gotten a
  few commits into stable, but have nothing to show for it in
  stack-analytics (if I'm doing it wrong, I'm happy to be
  corrected).
 [...]
 Stackalytics isn't an official OpenStack project, but you should
 file a bug[2] against it if there's a feature you want its authors
 to consider adding.


Stackalytics tracks commits into stable branches, e.g. for Neutron
stable/juno they are visible at
http://stackalytics.com/?metric=commitsmodule=neutronrelease=juno.
Commits are also shown in activity log for specific project or person, so
if someone interested in pulling them into weekly report - they will be
there.

Thanks,
Ilya

2015-02-10 19:45 GMT+03:00 Jeremy Stanley fu...@yuggoth.org:

 On 2015-02-10 15:20:46 + (+), Kevin Bringard (kevinbri) wrote:
 [...]
  I've been talking with a few people about this very thing lately,
  and I think much of it is caused by what appears to be our
  actively discouraging people from working on it. Most notably, ATC
  is only being given to folks committing to the current branch
  (
 https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/
 ).

 The comments on that answer are somewhat misleading, so I'll follow
 up there as well to set the record straight. The script[1] which
 identifies ATCs for the purpose of technical elections and summit
 passes is based entirely on Gerrit owners (uploaders) of changes
 merged to official projects within a particular time period. It
 doesn't treat master differently from any other branches. People who
 do the work to upload backports to stable branches absolutely do get
 counted for this purpose. People who only review changes uploaded by
 others do not (unless they are manually added to the extra-atcs
 file in the openstack/governance repo), but that is the case for all
 branches including master so not something stable-branch specific.

 Though I *personally* hope that is not the driving force to convince
 people to work on stable support. If it is, then we've already lost
 on this front.

  Secondly, it's difficult to get stack-analytics credit for back
  ports, as the preferred method is to cherry pick the code, and
  that keeps the original author's name. I've personally gotten a
  few commits into stable, but have nothing to show for it in
  stack-analytics (if I'm doing it wrong, I'm happy to be
  corrected).
 [...]

 Stackalytics isn't an official OpenStack project, but you should
 file a bug[2] against it if there's a feature you want its authors
 to consider adding.

 [1]
 https://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/atc/email_stats.py
 [2] https://bugs.launchpad.net/stackalytics/+filebug
 --
 Jeremy Stanley

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Kevin Bringard (kevinbri)

 On Feb 10, 2015, at 9:21 AM, Dean Troyer dtro...@gmail.com wrote:
 
 On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) 
 kevin...@cisco.com wrote:
 ATC is only being given to folks committing to the current branch 
 (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/).
  
 Secondly, it's difficult to get stack-analytics credit for back ports, as the 
 preferred method is to cherry pick the code, and that keeps the original 
 author's name.
  
 My fear is that we're going in a direction where trunk is the sole focus and 
 we're subsequently going to lose the support of the majority of the operators 
 and enterprises at which point we'll be a fun research project, but little 
 more.
 
 [I've cherry-picked above what I think are the main points here... not 
 directed at you Kevin.]

No offense taken! I just wanted to start a conversation about it, so mission 
accomplished :-D

 
 This is not Somebody Else's Problem.
 
 Stable maintenance is Not Much Fun, no question.  Those who have demanded the 
 loudest that we (the development community) maintain these stable branches 
 need to be the one supporting it the most. (I have no idea how that matches 
 up today, so I'm not pointing out anyone in particular.) 
 
 * ATC credit should be given, stable branch maintenance is a contribution to 
 the project, no question.

100% agree, which really is my entire point. 

I also noticed that since the original message went out, it's been clarified 
that current release is meant to mean any OpenStack contributions during the 
current release cycle (paraphrase based on my reading of the clarification), 
which would include stable branches.  I'm personally OK with this. I don't 
think the foundation should cover the cost of anyone who's contributed even a 
single bug fix in the last year (or whatever time period). Mostly I just want 
to make sure we're not scaring people away from working on stable branches. 
Like we've stipulated, maintenance isn't a lot of fun nor is it high profile. 
If we don't give people an incentive to do it, it's entirely likely they'll 
just say screw it.

 * I have a bit of a problem with stack-analytics being an issue partially 
 because that is not what should be driving corporate contributions and 
 resource allocation.  But it does.  Relying on a system with known anomalies 
 like the cherry-pick problem gets imperfect results.

Also agree. The only reason I mention it is that, as you stated, a lot of 
companies use it as a metric, and it does matter. If you want to get an 
OpenStack related job, chances are if you don't show up in Stack Analytics, 
you're going to have a harder time of it.

Jeremy made a good point that we should work that out with SA, which is 
unrelated to OpenStack specifically. Perhaps it's just a matter of better 
documenting how to properly commit to stable branches if you want it to be 
tracked.

 * The vast majority of the OpenStack contributors are paid to do their work 
 by a (most likely) Foundation member company.  These companies choose how to 
 allocate their resources, some do quite well at scratching their particular 
 itches, some just make a lot of noise.  If fun is what drives them to select 
 where they apply resources, then they will reap what they sow.

Again, I completely agree. But, as we've seen companies like to tout what 
they're doing. I personally do a lot of work on the stable branches, upstream 
when I can, but a lot of times I'm doing work on stuff that's been EOL or for 
which the issue I'm working on isn't considered stability work. In those 
cases my work never goes upstream. Combine this with the SA issues, and that's 
a lot of out of band work.

 
 The voice of operators/users/deployers in this conversation should be 
 reflected through the entity that they are paying to provide operational 
 cloud services.  It's those directly consuming the code from openstack.org 
 that are responsible here because they are the ones directly making money by 
 either providing public/private cloud services, or reselling a productized 
 OpenStack or providing consulting services and the like.
 
 This should not stop users/operators from contributing information, 
 requirements or code in any way.  But if they have to go around their vendor 
 then that vendor has failed them.

This, I disagree with. Not only does it make the assumption that anyone running 
OS for profit is either chasing trunk or paying a vendor, but it creates a 
potential fragmentation nightmare and chokes down the number of entities 
willing to invest into the project.

If I'm paying vendor X for operational cloud services, and it's stated that 
they're who should be voicing my interests in the community 1) What happens 
when my interests and that of another customer of vendor X conflict? But 2) Why 
should I invest in the community? I'm paying a vendor, it's their problem. In 
fact, why do I even have operators who could potentially contribute 

Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Mark Voelker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The sentiment that Kevin is expressing here has come up informally at past 
Operator’s meetups as well, which makes sense given that relatively few 
operators are chasing trunk vs using a stable release.  I would hypothesize 
that there’s probably actually a fair bit of interest among operators in having 
well maintained stable branches but there are disincentives that keep them from 
pitching in more.  Let’s see if we can bring that to light a bit—I’ve added an 
item on the etherpad to discuss this in Philadelphia at the Operator’s midcycle 
meetup in a few weeks. [1]  If folks who are attending aren’t familiar with the 
current stable branch policies and team structure, you may want to read through 
the wiki first. [2]

[1] https://etherpad.openstack.org/p/PHL-ops-meetup

[2] https://wiki.openstack.org/wiki/StableBranch

At Your Service,

Mark T. Voelker
OpenStack Architect

On Feb 10, 2015, at 10:20 AM, Kevin Bringard (kevinbri) kevin...@cisco.com 
wrote:

Since this is sort of a topic change, I opted to start a new thread. I was 
reading over the Juno is Fubar at the Gate thread, and this bit stood out to 
me:

So I think it's time we called the icehouse branch and marked it EOL. We
originally conditioned the longer support window on extra people stepping
forward to keep things working. I believe this latest issue is just the latest
indication that this hasn't happened. Issue 1 listed above is being caused by
the icehouse branch during upgrades. The fact that a stable release was pushed
at the same time things were wedged on the juno branch is just the latest
evidence to me that things aren't being maintained as they should be. Looking at
the #openstack-qa irc log from today or the etherpad about trying to sort this
issue should be an indication that no one has stepped up to help with the
maintenance and it shows given the poor state of the branch.

Most specifically: 

We originally conditioned the longer support window on extra people stepping 
forward to keep things working ... should be an indication that no one has 
stepped up to help with the maintenance and it shows given the poor state of 
the branch.

I've been talking with a few people about this very thing lately, and I think 
much of it is caused by what appears to be our actively discouraging people 
from working on it. Most notably, ATC is only being given to folks committing 
to the current branch 
(https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/).
 Secondly, it's difficult to get stack-analytics credit for back ports, as the 
preferred method is to cherry pick the code, and that keeps the original 
author's name. I've personally gotten a few commits into stable, but have 
nothing to show for it in stack-analytics (if I'm doing it wrong, I'm happy to 
be corrected).

My point here isn't to complain that I, or others, are not getting credit, but 
to point out that I don't know what we expected to happen to stable branches 
when we actively dis-incentivize people from working on them. Working on 
hardening old code is generally far less interesting than working on the cool 
shiny new features, and many of the productionalization issues we run into 
aren't uncovered until it's being run at scale which in turn is usually by a 
big company who likely isn't chasing trunk.

My fear is that we're going in a direction where trunk is the sole focus and 
we're subsequently going to lose the support of the majority of the operators 
and enterprises at which point we'll be a fun research project, but little more.

- - -- Kevin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

- -BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU2i1eAAoJELUJLUWGN7CbmPEQAKV/9RPgKt6jwvq0bzhFCJPF
hz2LOC8M5Fk1wINGUcvwGjiphCwGMSD9p6IYx7PAzMrnbhLqQa0exCmo4DUi3jdV
qNC1A6juScrHjyQMcQ3dBS4Z4QEh0S964n2Ae/uoWydpDe8WGy4DQRLTNy+mCIg5
ROManHAWcQ3Cr5fYkFSeGQgaoROypj2Eebvv4kiYDPQVkjK1o49hpybxe5v0zR/Y
6kuacoZCK8h6X8b4CrbG+t/vCy8dqWIUB1j67VBojRDpe1p0yQqA3IJ72DLPfTw5
0GzUecfW781ZP5fHQSwhbg7t31UYXBpo9xszltXBiNynHRktA7BwYwj+YAFCKgNZ
sQ/gZOruqR+Os8/+pngA23PCGvuCUsTamUCkQUs4mCHjdvPq/BNFg0qGNeeheLQq
CzlldwqcPY5py3KfmipIZakH1wZ2S/DU/snuAhVatTjVHqO1leyk5asHYVVAnwCQ
96vawAHcIXEN4dPcXpcYBiiTE1mgq+0FQgVGsr4fQ2BkRYDN9rmOdVp+mG7b7QM0
jhK+POQqj+ojnQOKwA2ygQUglDY8MxjmfCrMukkWQylmYVb09Z0cOMFfMMw7YfU3
pWGP6BIfCManduqVBqFvTMxh/dCGIGq3LwrXo23qmukdgSIVRuj16XPZqXZ5xtv/
A6NV//pQXxvO4d+l4bBk
=cT3X
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU2i1jAAoJELUJLUWGN7CbsDIP/i0CyFC1FOL7SSC3IFLvVd9r