[openstack-dev] IMPORTANT: This list is retired

2018-12-03 Thread Jeremy Stanley
This mailing list was replaced by a new
openstack-disc...@lists.openstack.org mailing list[0] as of Monday
November 19, 2018 and starting now will no longer receive any new
messages. The archive of prior messages will remain published in the
expected location indefinitely for future reference.

For convenience posts to the old list address will be rerouted to
the new list for an indeterminate period of time, but please correct
it in your replies if you notice this.

See my original notice[1] (and the many reminders sent in months
since) for an explanation of this change.

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] IMPORTANT: We're combining the lists!

2018-11-27 Thread Jeremy Stanley
REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this was sent) are being
replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list[0] has been open for posts from subscribers since
Monday November 19, and the old lists will be configured to no
longer accept posts starting on Monday December 3. In the interim,
posts to the old lists will also get copied to the new list so it's
safe to unsubscribe from them now and not miss any messages. See my
previous notice[1] for details.

As of the time of this announcement, we have 403 subscribers on
openstack-discuss with six days to go before the old lists are
closed down for good). I have updated the old list descriptions to
indicate the openstack-discuss list is preferred, and added a custom
"welcome message" with the same for anyone who subscribes to them
over the next week.

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] IMPORTANT: We're combining the lists!

2018-11-18 Thread Jeremy Stanley
REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this was sent) are being
replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list[0] is open for posts from subscribers starting
now, and the old lists will be configured to no longer accept posts
starting on Monday December 3. In the interim, posts to the old
lists will also get copied to the new list so it's safe to
unsubscribe from them now and not miss any messages. See my previous
notice[1] for details.

As of the time of this announcement, we have 280 subscribers on
openstack-discuss with three weeks to go before the old lists are
closed down for good). At the recommendation of David Medberry at
the OpenStack Summit last week, this reminder is being sent
individually to each of the old lists (not as a cross-post), and
without any topic tag in case either might be resulting in
subscribers missing it.

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] We're combining the lists!

2018-11-10 Thread Jeremy Stanley
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote:
[...]
> As we are ultimately planning to move lists to mailman3 (which decided
> to drop the "topics" concept altogether), I don't think we planned to
> add serverside mailman topics to the new list.

Correct, that was covered in more detail in the longer original
announcement linked from my past couple of reminders:

http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html

In short, we're recommending client-side filtering because
server-side topic selection/management was not retained in Mailman 3
as Thierry indicates and we hope we might move our lists to an MM3
instance sometime in the not-too-distant future.

> We'll still have standardized subject line topics. The current list
> lives at:
> 
> https://etherpad.openstack.org/p/common-openstack-ml-topics

Which is its initial location for crowd-sourcing/brainstorming, but
will get published to a more durable location like on
lists.openstack.org itself or perhaps the Project-Team Guide once
the list is in use.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] We're combining the lists!

2018-11-09 Thread Jeremy Stanley
REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 207 subscribers so far on
openstack-discuss with a little over a week to go before it will be
put into use (and less than a month before the old lists are closed
down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [neutron][neutron-release] feature/graphql branch rebase

2018-11-09 Thread Jeremy Stanley
On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote:
> Could you please provide permission [1] to upload commit merges?
> 
> I'm getting the following error after merging HEAD:
> 
> $ git review -R feature/graphql
> remote:
> remote: Processing changes: refs: 1
> remote: Processing changes: refs: 1, done
> To ssh://review.openstack.org:29418/openstack/neutron.git
>  ! [remote rejected]   HEAD -> refs/publish/feature/graphql/bug/1802101
> (you are not allowed to upload merges)
> error: failed to push some refs to
> 'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git'
[...]

Per openstack/neutron's ACL[*] you need to be made a member of the
neutron-release group in Gerrit[**]. (This permission is tightly
controlled to avoid people accidentally pushing merge commits, which
is all too easy if you're not careful to keep your branches clean.)

[*] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config
[**] https://review.openstack.org/#/admin/groups/neutron-release
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [cyborg]Weekly Meeting

2018-11-07 Thread Jeremy Stanley
On 2018-11-07 10:02:52 -0500 (-0500), Li Liu wrote:
> It seems the meeting bot is having issues.. I would just paste the
> meeting log here
[...]

The meetbot wasn't having any issues. The chair didn't issue an
#endmeeting, and only a meeting chair is allowed to do so until an
hour has elapsed from the #startmeeting. After an hour, anyone can
so I did an #endmeeting in your channel and it wrapped up and wrote
the minutes and logs as usual:

http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-11-07-14.16.html

-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

2018-11-06 Thread Jeremy Stanley
On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote:
[...]
> also add jobs like "devstack-xenial" and "tempest-full-xenial"
> which projects can use still for some time if their job on Bionic
> would be broken now?
[...]

That opens the door to piecemeal migration, which (as we similarly
saw during the Trusty to Xenial switch) will inevitably lead to
projects who no longer gate on Xenial being unable to integration
test against projects who don't yet support Bionic. At the same
time, projects which have switched to Bionic will start merging
changes which only work on Bionic without realizing it, so that
projects which test on Xenial can't use them. In short, you'll be
broken either way. On top of that, you can end up with projects that
don't get around to switching completely before release comes, and
then they're stuck having to manage a test platform transition on a
stable branch.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] 2019 summit during May holidays?

2018-11-05 Thread Jeremy Stanley
On 2018-11-05 11:06:14 -0800 (-0800), Julia Kreger wrote:
[...]
> I imagine that as a community, it is near impossible to schedule
> something avoiding holidays for everyone in the community.
[...]

Scheduling events that time of year is particularly challenging
anyway because of the proximity of Ramadan, Passover and
Easter/Lent. (We've already conflicted with Passover at least once
in the past, if memory serves.) So yes, any random week you pick is
already likely to hit a major public or religious holiday for
some part of the World, and then you also have to factor in
availability of venues and other logistics.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures][release][infra] Tag of openstack/keystone failed

2018-11-01 Thread Jeremy Stanley
On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote:
> Jeremy Stanley  writes:
> 
> > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >> Did I miss any options or issues with this approach?
> >
> > https://review.openstack.org/578557
> 
> How high of a priority is rolling that feature out? It does seem to
> eliminate this particular issue (even the edge cases described in the
> commit message shouldn't affect us based on our typical practices), but
> until we have one of the two changes in place we're going to have this
> issue with every release we tag.

It was written as a potential solution to this problem back when we
first discussed it in June, but at the time we thought it might be
solvable via job configuration with minimal inconvenience so that
feature was put on hold as a fallback option in case we ended up
needing it. I expect since it's already seen some review and is
passing tests it could probably be picked back up fairly quickly now
that alternative solutions have proven more complex than originally
envisioned.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures][release][infra] Tag of openstack/keystone failed

2018-11-01 Thread Jeremy Stanley
On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
[...]
> Did I miss any options or issues with this approach?

https://review.openstack.org/578557

-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] Storyboard python script

2018-10-31 Thread Jeremy Stanley
On 2018-10-31 22:39:01 + (+), Krishna Jain wrote:
> I’m an animator with some coding experience picking up Python. I
> came across your python-storyboardclient library, which would be
> very helpful for automating our pipeline in Toon Boom Storyboard
> Pro.
[...]

The python-storyboardclient library is for use with the free/libre
open source StoryBoard task and defect tracker project described by
the documentation located at
https://docs.openstack.org/infra/storyboard/ and not the commercial
"Toon Boom Storyboard Pro" animation software to which you seem to
be referring. Sorry for the confusion!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] We're combining the lists!

2018-10-29 Thread Jeremy Stanley
On 2018-10-29 12:58:09 -0400 (-0400), Jay Pipes wrote:
> I'm not willing to subscribe with a password over a non-TLS
> connection...
[...]

Up to you, certainly. You don't actually need to enter anything in
the password fields on the subscription page (as the instructions on
it also indicate). You can alternatively subscribe by sending E-mail
to openstack-discuss-requ...@lists.openstack.org with a subject line
of "subscribe" if you prefer.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] We're combining the lists! (was: Bringing the community together...)

2018-10-29 Thread Jeremy Stanley
REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 127 subscribers so far on
openstack-discuss with 3 weeks to go before it will be put into use
(and 5 weeks now before the old lists are closed down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures] Release of openstack/python-apmecclient failed

2018-10-26 Thread Jeremy Stanley
On 2018-10-26 06:46:23 -0500 (-0500), Sean McGinnis wrote:
[...]
> Release failed for this due to openstackci not being properly configured
> for the pypi package upload.

If whoever "pineunity" is can add the "openstackci" account as
another maintainer for https://pypi.org/project/python-apmecclient/
then I'm happy to reenqueue that tag into Zuul.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures] Release of openstack-infra/shade failed

2018-10-24 Thread Jeremy Stanley
On 2018-10-24 16:08:26 +1100 (+1100), Tony Breeds wrote:
> On Wed, Oct 24, 2018 at 03:23:53AM +, z...@openstack.org wrote:
> > Build failed.
> > 
> > - release-openstack-python3 
> > http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python3/e84da68/
> >  : POST_FAILURE in 2m 18s
> 
> So this failed because pypi thinks there was a name collision[1]:
>  HTTPError: 400 Client Error: File already exists. See 
> https://pypi.org/help/#file-name-reuse for url: 
> https://upload.pypi.org/legacy/
> 
> AFACIT the upload was successful:
> 
> shade-1.27.2-py2-none-any.whl  : 2018-10-24T03:20:00 
> d30a230461ba276c8bc561a27e61dcfd6769ca00bb4c652a841f7148a0d74a5a
> shade-1.27.2-py2.py3-none-any.whl  : 2018-10-24T03:20:11 
> 8942b56d7d02740fb9c799a57f0c4ff13d300680c89e6f04dadb5eaa854e1792
> shade-1.27.2.tar.gz: 2018-10-24T03:20:04 
> ebf40040b892f3e9bd4229fd05fff7ea24a08c51e46b7f2d8b3901ce34f51cbf
[...]

I think PyPI is right. Note the fact that there are not two but
*three* artifacts there. We shouldn't be building both a py2 and
py2.py3 wheel. The log you linked is uploaded
shade-1.27.2-py2.py3-none-any.whl and tried (but failed) to upload
shade-1.27.2.tar.gz. So where did shade-1.27.2-py2-none-any.whl come
from then? Hold onto your hats folks:

http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python/f38f2b9/job-output.txt.gz#_2018-10-24_03_20_02_134223

I suppose we don't expect a project to run both the
release-openstack-python and release-openstack-python3 jobs on the
same tags.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] Naming the T release of OpenStack

2018-10-18 Thread Jeremy Stanley
On 2018-10-18 08:35:21 -0500 (-0500), Jay S Bryant wrote:
[...]
> When OpenStack developers think Denver, we think Trains.  :-)
[...]

As, presumably, do many OpenStack operators now since the Ops
Mid-Cycle event was co-located with the most recent PTG.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [requirements][vitrage][infra] SQLAlchemy-Utils version 0.33.6 breaks Vitrage gate

2018-10-18 Thread Jeremy Stanley
On 2018-10-18 14:57:23 +0200 (+0200), Andreas Jaeger wrote:
> On 18/10/2018 14.15, Ifat Afek wrote:
> > Hi,
> > 
> > In the last three days Vitrage gate is broken due to the new requirement
> > of SQLAlchemy-Utils==0.33.6.
> > We get the following error [1]:
> > 
> > [...] >
> > Can we move back to version 0.33.5? or is there another solution?
> 
> We discussed that on #openstack-infra, and fixed it each day - and then it
> appeared again.
> 
> https://review.openstack.org/611444 is the proposed fix for that - the
> issues comes from the fact that we build wheels if there are none available
> and had a race in it.
> 
> I hope an admin can delete the broken file again and it works again tomorrow
> - if not, best to speak up quickly on #openstack-infra,

It's been deleted (again) and the suspected fix approved so
hopefully it won't recur.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 17:34:24 -0400 (-0400), Corey Bryant wrote:
[...]
> I was assuming the desire to keep 3.5 stein support was for other distros
> that plan to support stein with 3.5.

If there are other distros which are planning to support OpenStack
Stein on Python 3.5, then they should work with us to get testing in
place on systems running their distro. That said, I'd be surprised
if a new LTS server release of a distro targets Python 3.5... it's
already over 3 years old, and 3.3 and 3.4 each got roughly 5 years
before EOL so I'd expect 3.5 to no longer be supported upstream past
September 2020.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote:
[...]
> That said, I don't think we should be dropping support/testing for 3.5.
> According to:
> 
>   https://governance.openstack.org/tc/reference/pti/python.html
> 
> 3.5 is the only Python3 version that we require all projects to run tests
> for.

Until we update it to refer to the version provided by the test
platforms we document at:

https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions

> Out goal is to get everyone running 3.6 unit tests by the end of Stein:
> 
> https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs
> 
> but we explicitly said there that we were not dropping support for 3.5 as
> part of the goal, and should continue to do so until we can effect an
> orderly transition later.
[...]

We're not dropping support for 3.5 as part of the python3-first
goal, but would be dropping it as part of the switch from Ubuntu
16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides
Python 3.6). In the past the OpenStack Infra team has prodded us to
follow our documented testing platform policies as new versions
become available, but now with a move to providing infrastructure
services to other OSF projects as well we're on our own to police
this.

We _could_ decide that we're going to start running tests on
multiple versions of Python 3 indefinitely (rather than as a
transitional state during the switch from Ubuntu Xenial to Bionic)
but that does necessarily mean running more jobs. We could also
decide to start targeting different versions of Python than provided
by the distros on which we run our tests (and build it from source
ourselves or something) but I think that's only reasonable if we're
going to also recommend that users deploy OpenStack on top of
custom-compiled Python interpreters rather than the interpreters
provided by server distros like RHEL and Ubuntu.

So to sum up the above, it's less a question of whether we're
dropping Python 3.5 testing in Stein, and more a question of whether
we're going to continue requiring OpenStack to also be able to run
on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start
of the cycle).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [infra] Polygerrit (was: [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo)

2018-10-15 Thread Jeremy Stanley
On 2018-10-15 11:54:28 +0100 (+0100), Stephen Finucane wrote:
[...]
> As an aside, are there any plans to enable PolyGerrit [1] in the
> OpenStack Gerrit instance?
[...]

I believe so, but first we need to upgrade to a newer Gerrit version
which provides it (that in turn requires a newer Java which needs a
server built from a newer distro version, which is all we've gotten
through on the upgrade plan so far).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc][all] meetings outside IRC

2018-10-13 Thread Jeremy Stanley
On 2018-10-13 23:29:46 +0200 (+0200), Mohammed Naser wrote:
> I was going over our governance documents, more specifically this
> section:
> 
> "All project meetings are held in public IRC channels and
> recorded."
> 
> Does this mean that all official projects are *required* to hold
> their project meetings over IRC?

If an official project team holds a regular official team meeting,
then it needs to be in a public IRC channel with published logs
(either the channel log or a log specific to the meeting).

> Is this a hard requirement or is this something that we're a bit
> more 'lax about?
[...]

We've not generally required this of auxiliary meetings for official
teams. Sub-team meetings and unofficial/ad-hoc team discussions over
conference call or video chat media have been tolerated in the past.
But for an official team meeting (if the team regularly holds one)
we've stuck to the quoted expectation as a requirement as far as I'm
aware.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 16:35:38 -0700 (-0700), Goutham Pacha Ravi wrote:
[...]
> Thanks Corey for starting this effort. I proposed changes to
> manila repos to use your template [1] [2], but the interpreter's
> not being installed, do you need to make any bindep changes to
> enable the "universe" ppa and install python3.7 and python3.7-dev?
[...]

I think we need to just make sure that the standard Python jobs
install the intended version of the interpreter. Using bindep for
that particular purpose is mildly silly. The bindep.txt file is,
first and foremost, a local developer convenience to let people know
what unexpected packages they might need to install on their systems
to run certain kinds of local tests. I really doubt any reasonable
developer will be surprised that they need to install python3.7
before being able to successfully run `tox -e py37` nor is the error
message confusing if they forget to do so.

A couple projects have added python-version-specific bindep profiles
which do nothing but install the corresponding interpreter, but
adding things to bindep.txt purely to satisfy the CI system is
backwards. Our CI jobs should do what we expect them to do by
default. If the job says it's going to run unit tests under Python
3.7 then the job should make sure a suitable interpreter is
installed to do so.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote:
[...]
> I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and
> 3.7.
[...]

I might have only pointed this out on IRC so far, but the
expectation is that testing 3.5 and 3.6 at the same time was merely
transitional since official OpenStack projects should be moving
their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu
Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein
cycle and so will drop 3.5 testing on master in the process.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote:
[...]
> We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs
> past muster before being merged, so it's not like we're wanting to
> circumvent good contribution practices by committing whatever to HEAD.

Travis CI has gained the ability to prevent you from merging changes
which fail testing? Or do you mean something else when you refer to
it as a "gatekeeper" here?

> But the +2/+W rights thing was a huge PITA to deal with with so
> few contributors, for sure.
[...]

Note that this is not a technical limitation at all, merely social
convention. There are plenty of projects hosted on our
infrastructure, some even official OpenStack projects, where
contributor count is low enough that authors who are also core
reviewers just review and approve their own changes for expediency.

> There's also a sense that if a project is in the Openstack
> umbrella, it's not useful outside Openstack, and Taskflow is
> designed to be a general purpose library.
[...]

Be aware that the "OpenStack Infrastructure" is in the process of
rebranding itself as "OpenDev" and we're working to eliminate
mention of OpenStack on things that don't need it. This includes
moving services to a new domain name, switching to other repository
namespaces, putting mirroring to services like GitHub and Bitbucket
under the direct control of teams who are interested in handling
that with their own unique organizations in those platforms, and so
on. It's progressing, though perhaps too slowly to solve your
immediate concerns.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 16:09:21 +0200 (+0200), Andreas Jaeger wrote:
[...]
> So, I'm asking whether there is a good way to not duplicating all
> jobs to run on all three interpreters. Do we really need testing
> of all three versions? Or is testing with a subset a manageable
> risk?

OpenStack projects are hopefully switching to testing on Bionic
instead of Xenial during the Stein cycle, so will stop testing with
Python 3.5 on master when that happens (since Bionic provides
3.6/3.7 and no 3.5).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 09:38:14 -0400 (-0400), Corey Bryant wrote:
[...]
> Another option could be to use a non-LTS image to use a supported
> release.

Let's avoid creating additional images unless there is a strong
reason (every additional image means more load on our image
builders, more space consumed in our providers, et cetera). Bionic
seems like it will serve fine for this purpose now that it's got
more than a pre-release of 3.7.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [python3] Enabling py37 unit tests

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 08:45:39 -0400 (-0400), Corey Bryant wrote:
[...]
> Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter
[...]

Thanks for the heads up! Last time I looked it was still a pre-3.7.0
beta package, but looks like that has finally been updated to a
proper release of the interpreter for Bionic in the last few weeks?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [api] Open API 3.0 for OpenStack API

2018-10-10 Thread Jeremy Stanley
On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:
> On 09/10/18 23:58, Jeremy Stanley wrote:
> > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> > [...]
> > > It seems to me that a major goal of openstacksdk is to hide
> > > differences between clouds from the user. If the user is meant
> > > to use a GraphQL library themselves, we lose this and the user
> > > needs to figure it out themselves. Did I understand that
> > > correctly?
> > This is especially useful where the SDK implements business
> > logic for common operations like "if the user requested A and
> > the cloud supports features B+C+D then use those to fulfil the
> > request, otherwise fall back to using features E+F".
> 
> The features offered to the user don't have to change, it's just a
> different architecture.
> 
> The user doesn't have to deal with a GraphQL library, only the
> client applications (consuming OpenStack APIs). And there are also
> UI tools such as GraphiQL which allow to interact directly with
> GraphQL servers.

My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.

Can you explain how GraphQL eliminates the above reasons for an SDK?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [api] Open API 3.0 for OpenStack API

2018-10-09 Thread Jeremy Stanley
On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]
> It seems to me that a major goal of openstacksdk is to hide differences
> between clouds from the user. If the user is meant to use a GraphQL library
> themselves, we lose this and the user needs to figure it out themselves.
> Did I understand that correctly?

This is especially useful where the SDK implements business logic
for common operations like "if the user requested A and the cloud
supports features B+C+D then use those to fulfil the request,
otherwise fall back to using features E+F".
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][Searchlight] Always build universal wheels

2018-10-05 Thread Jeremy Stanley
On 2018-10-05 07:20:01 -0400 (-0400), Doug Hellmann wrote:
[...]
> So, I think this all means we can leave the setup.cfg files as
> they are and not worry about updating the wheel format flag.

I continue to agree that, because of the reasons you state, it is
not urgent to update setup.cfg (either to start supporting universal
wheels or to follow the deprecation/transition on the section name
in the latest wheel release), at least for projects relying on the
OpenStack-specific release jobs. It is still technically more
correct and I don't think we should forbid individual teams from
also updating the setup.cfg files in their repositories should they
choose to do so. That's all I've been trying to say.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc] bringing back formal TC meetings

2018-10-05 Thread Jeremy Stanley
On 2018-10-05 07:40:00 -0400 (-0400), Doug Hellmann wrote:
[...]
> I had in mind "email the chair your topic suggestion" and then "the
> chair emails the agenda to openstack-dev tagged [tc] a bit in advance of
> the meeting". There would also probably be some standing topics, like
> updates for ongoing projects.
> 
> Does that work for everyone?
[...]

Seems fine to me.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures] Release of openstack/os-log-merger failed

2018-10-04 Thread Jeremy Stanley
On 2018-10-04 18:21:50 -0400 (-0400), Doug Hellmann wrote:
> Jeremy Stanley  writes:
> 
> > On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
> >>   'Topic:: Utilities' is not a valid choice for this field for url:
> >>   https://upload.pypi.org/legacy/
> >> 
> >> I'm not aware of any way to test those values easily before doing an
> >> upload. If someone knows of a way, please let me know.
> >
> > I started writing a distcheck utility based on some validation code
> > flit uses, but now that twine has a check option there is expressed
> > intent by Dustin to do it there (see description of
> > https://github.com/pypa/twine/pull/395 for details) which seems like
> > a more natural solution anyway.
> 
> OK, good. The existing check job for packaging already runs 'twine
> check' so we should be covered when that feature is merged and released.

Well, the TODO comment at
https://github.com/pypa/warehouse/blob/55230d8/warehouse/forklift/legacy.py#L341-L343
expresses an interest in seeing Warehouse's (the current PyPI
implementation) metadata validation code move to the
https://pypi.org/project/packaging/ library, which should be clear
to progress now that https://www.python.org/dev/peps/pep-0459/
(which supplanted the withdrawn PEP 426 mentioned in the TODO) has
been finalized. Someone still needs to do that work, and then update
`twine check` to use it (probably won't be me either, unless I
somehow grow some extra spare time). This would be an awesome
project for *someone* interested in making new inroads in the Python
packaging community.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Release-job-failures] Release of openstack/os-log-merger failed

2018-10-04 Thread Jeremy Stanley
On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
[...]
>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
>   'Topic:: Utilities' is not a valid choice for this field for url:
>   https://upload.pypi.org/legacy/
> 
> I'm not aware of any way to test those values easily before doing an
> upload. If someone knows of a way, please let me know.

I started writing a distcheck utility based on some validation code
flit uses, but now that twine has a check option there is expressed
intent by Dustin to do it there (see description of
https://github.com/pypa/twine/pull/395 for details) which seems like
a more natural solution anyway.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [tc] bringing back formal TC meetings

2018-10-04 Thread Jeremy Stanley
On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
[...]
> TC members, please reply to this thread and indicate if you would
> find meeting at 1300 UTC on the first Thursday of every month
> acceptable, and of course include any other comments you might
> have (including alternate times).

This time is acceptable to me. As long as we ensure that community
feedback continues more frequently in IRC and on the ML (for example
by making it clear that this meeting is expressly *not* for that)
then I'm fine with resuming formal meetings.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][Searchlight] Always build universal wheels

2018-10-04 Thread Jeremy Stanley
On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
[...]
> Please avoid adding universal wheels to the project setup.cfg.
[...]

Why would you avoid also adding it to the setup.cfg? The change you
cited is merely to be able to continue building universal wheels for
projects while the setup.cfg files are corrected over time, to
reduce the urgency of doing so. Wheel building happens in more
places than just our CI system, so only fixing it in CI is not a
good long-term strategy.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [goal][python3] week 7 update

2018-09-28 Thread Jeremy Stanley
On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote:
> Doug Hellmann  wrote on 09/26/2018 06:29:11 PM:
> 
> > * We do not want to set the override once in testenv, because that
> >   breaks the more specific versions used in default environments like
> >   py35 and py36 (at least under older versions of tox).
> 
> 
> I assume that something like
> https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=fa64a93c965e6a6692711962ad6584534da81695
>  should be a perfectly acceptable alternative in at least some cases.
> Agreed?

I believe the confusion is that ignore_basepython_conflict didn't
appear in a release of tox until after we started patching projects
for this effort (in fact it was added to tox in part because we
discovered the issue in originally attempting to use basepython
globally).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)

2018-09-28 Thread Jeremy Stanley
On 2018-09-28 08:51:46 -0300 (-0300), Erlon Cruz wrote:
> I don't know if our workflow supports this, but it would be nice
> to have a place to place cross-projec changes like that (something
> like, openstack-cross-projects-specs), and use that as a initial
> point for high level discussions. But for now, you can start
> creating specs for the projects involved.
[...]

If memory serves, the biggest challenge around that solution was
determining who approves such proposals since they still need
per-project specs for the project-specific details anyway. Perhaps
someone who has recently worked on a feature which required
coordination between several teams (but not a majority of teams like
our cycle goals process addresses) can comment on what worked for
them and what improvements they would make on the process they
followed.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][tc][elections] Stein TC Election Results

2018-09-27 Thread Jeremy Stanley
On 2018-09-27 20:00:42 -0400 (-0400), Mohammed Naser wrote:
[...]
> A big thank you to our election team who oversees all of this as
> well :)
[...]

I wholeheartedly concur!

And an even bigger thank you to the 5 candidates who were not
elected this term; please run again in the next election if you're
able, I think every one of you would have made a great choice for a
seat on the OpenStack TC. Our community is really lucky to have so
many qualified people eager to take on governance tasks.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [ptl][release] Proposed changes for cycle-with-milestones deliverables

2018-09-26 Thread Jeremy Stanley
On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote:
[...]
> It tests the release automation machinery to identify problems
> before the RC and final release crunch time.
[...]

More to the point, it helped spot changes to projects which made it
impossible to generate and publish their release artifacts. Coverage
has improved for finding these issues before merging now, as well as
in flight tests on proposed releases, making the risk lower than it
used to be.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [storyboard] why use different "bug" tags per project?

2018-09-26 Thread Jeremy Stanley
On 2018-09-26 00:50:16 -0600 (-0600), Chris Friesen wrote:
> At the PTG, it was suggested that each project should tag their bugs with
> "-bug" to avoid tags being "leaked" across projects, or something
> like that.
> 
> Could someone elaborate on why this was recommended?  It seems to me that
> it'd be better for all projects to just use the "bug" tag for consistency.
> 
> If you want to get all bugs in a specific project it would be pretty easy to
> search for stories with a tag of "bug" and a project of "X".

Because stories are a cross-project concept and tags are applied to
the story, it's possible for a story with tasks for both
openstack/nova and openstack/cinder projects to represent a bug for
one and a new feature for the other. If they're tagged nova-bug and
cinder-feature then that would allow them to match the queries those
teams have defined for their worklists, boards, et cetera. It's of
course possible to just hand-wave that these intersections are rare
enough to ignore and go ahead and use generic story tags, but the
recommendation is there to allow teams to avoid disagreements in
such cases.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [storyboard] Prioritization?

2018-09-24 Thread Jeremy Stanley
On 2018-09-24 19:31:17 -0400 (-0400), Doug Hellmann wrote:
> That came up as a suggestion, too. The challenge there is that we
> cannot (as far as I know) sort on tags. So even if we have tags,
> we can't create a list of stories that is ordered automatically
> based on the priority. Maybe there's a solution to that?

A board with automatic lanes for each priority tag? That way you can
also have a lane for "stories with incomplete tasks for projects in
my project-group but which haven't been prioritized yet" and be able
to act on/triage them accordingly.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [storyboard] Prioritization?

2018-09-24 Thread Jeremy Stanley
On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
[...]
> At the PTG there was feedback from at least one team that
> consumers of the data in storyboard want a priority setting on
> each story. Historically the response to that has been that
> different users will have different priorities, so each of them
> using worklists is the best way to support those differences of
> opinion.
> 
> I think we need to reconsider that position if it's going to block
> adoption. I think Ben's case is an excellent second example of
> where having a field to hold some sort of priority value would be
> useful.

The alternative suggestion, for teams who want to be able to flag
some sort of bucketed priorities, is to use story tags. We could
even improve the import tool to accept some sort of
priority-to-tag-name mapping so that, say, when we import bugs for
Oslo their oslo-critical tag is applied to any with a critical
bugtask, oslo-medium to any with medium priority tasks, and so on.
Not all teams using StoryBoard will want to have a bucketed priority
scheme, and those who do won't necessarily want to use the same
number or kinds of priorities.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Capturing Feedback/Input

2018-09-21 Thread Jeremy Stanley
On 2018-09-21 12:55:09 -0500 (-0500), Melvin Hillsman wrote:
[...]
> Yeah unfortunately we do have a tendency to overthink/complicate
> things. Not saying Storyboard is the right tool but suggested
> rather than having something extra to maintain was what I
> understood. There are at least 3 things that were to be addressed:
> 
> - single pane so folks know where to provide/see updates

Not all OpenStack projects use the same task trackers currently and
there's no guarantee that they ever will, so this is a best effort
only. Odds are you may wind up duplicating some information also
present in the Nova project on Launchpad, the Tripleo project on
Trello and the Foobly project on Bugzilla (I made this last one up,
in case it's not obvious).

> - it is not a catchall/dumpsite

If it looks generic enough, it will become that unless there are
people actively devoted to triaging and pruning submissions to
curate them... a tedious and thankless long-term commitment, to be
sure.

> - something still needs to be flushed out/prioritized (Public
> Cloud WG's missing features spreadsheet for example)

This is definitely a good source of input, but still needs someone
to determine which various projects/services the tasks for them get
slotted into and then help prioritizing and managing spec
submissions on a per-team basis.

> - not specific to a single project (i thought this was a given
> since there is already a process/workflow for single project)

The way to do that on storyboard.openstack.org is to give it a
project of its own. Basically just couple it to a new, empty Git
repository and then the people doing these tasks still have the
option of also putting that repository to some use later (for
example, to house their workflow documentation).

> I could very well be wrong so I am open to be corrected. From my
> perspective the idea in the room was to not circumvent anything
> internal but rather make it easy for external viewers, passerbys,
> etc. When feedback is gathered from Ops Meetup, OpenStack Days,
> Local meetups/events, we discussed putting that here as well.

It seems a fine plan, just keep in mind that documenting and
publishing feedback doesn't magically translate into developers
acting on any of it (and this is far from the first time it's been
attempted).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [release][collectd-openstack-plugins] Schedule new release?

2018-09-21 Thread Jeremy Stanley
On 2018-09-21 05:53:08 -0500 (-0500), Sean McGinnis wrote:
[...]
> collectd-openstack-plugins does not appear to be an official repo under
> governance [1]. For these types of projects to do a release, the team would
> need to push a tag to the repo. That will trigger some post jobs to run that
> will create and publish tarballs. Some basic information (though slightly
> different context) can be found here [2].
> 
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
> [2] 
> https://docs.openstack.org/infra/manual/creators.html#prepare-an-initial-release

Perhaps slightly more aligned with the context of the question is
this document:
https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)

2018-09-20 Thread Jeremy Stanley
On 2018-09-20 15:46:43 -0600 (-0600), Doug Hellmann wrote:
[...]
> Since last week there was some discussion of including the openstack-tc
> mailing list among these lists to eliminate confusion caused by the fact
> that the list is not configured to accept messages from all subscribers
> (it's meant to be used for us to make sure TC members see meeting
> announcements).
[...]

I think it makes sense. The Interop WG also indicated they'd like to
do the same with theirs. In cases like these where the lists in
question have much lower volume anyway, I don't think any special
handling is needed. Basically any time after November 19 just send a
post to the old list saying that subsequent messages need to
go to openstack-discuss instead, and then immediately set it to no
longer accept new messages.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [all] We're combining the lists! (was: Bringing the community together...)

2018-09-20 Thread Jeremy Stanley
ryone from the four older lists to
the new one and call it a day? Well, I personally would find it rude
if a list admin mass-subscribed me to a mailing list I hadn't
directly requested. Doing so may even be illegal in some
jurisdictions (we could probably make a case that it's warranted,
but it's cleaner to not need to justify such an action). Much like
the answer to the previous question, the changes in behavior (and
also in the list name itself) are likely to cause lots of
subscribers to need to update their message filtering rules anyway.
I know by default it would all start landing in my main inbox, and
annoy me mightily.

What subject tags are we going to be using to identify messages of
interest and to be able to skip those we don't care about? We're
going to continuously deploy a list of recommended subject tags in a
visible space, either on the listserv's WebUI or the Infra Manual
and link to it liberally. There is already an initial set of
suggestions[5] being brainstormed, so feel free to add any there you
feel might be missing. It's not yet been decided whether we'll also
include these in the Mailman "Topics" configuration to enable
server-side filtering on them (as there's a good chance we'll be
unable to continue supporting that after an upgrade to Mailman 3),
so for now it's best to assume you may need to add them to your
client-side filters if you rely on that capability.

If you have any further questions, please feel free to respond to
this announcement so we can make sure they're answered.

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134074.html
[3] https://etherpad.openstack.org/p/infra-ptg-denver-2018
[4] https://www.ietf.org/rfc/rfc2369.txt
[5] https://etherpad.openstack.org/p/common-openstack-ml-topics
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

2018-09-18 Thread Jeremy Stanley
On 2018-09-18 14:52:28 +0200 (+0200), Sylvain Bauza wrote:
[...]
> Why are we discussing about WeChat now? Is that because a large
> set of our contributors *can't* access IRC or because they
> *prefer* any other?

Until we get confirmation either way, I'm going to work under the
assumption that there are actual network barriers to using IRC for
these contributors and that it's not just a matter of preference. I
mainly want to know the source of these barriers because that will
determine how to go about addressing them.

If it's restrictions imposed by employers, it may be hard for
employees to raise the issue in predominantly confrontation-averse
cultures. The First Contact SIG is working on a document which
outlines the communications and workflows used by our community with
a focus on explaining to managers and other staff at contributing
organizations what allowances they can make to ease and improve the
experience of those they've tasked with working upstream.

If the barriers are instead imposed by national government, then
urging contributors within those borders to flaunt the law and
interact with the rest of our community over IRC is not something
which should be taken lightly. That's not to say it can't be solved,
but the topic then is a much more political one and our community
may not be an appropriate venue for those discussions.

> In the past, we made clear for a couple of times why IRC is our
> communication channel. I don't see those reasons to be invalid
> now, but I'm still open to understand the problems about why our
> community becomes de facto fragmented.

I think the extended community is already fragmented across a
variety of discussion fora. Some watch for relevant hashtags on
Twitter and engage in discussions there. I gather there's an
unofficial OpenStack Slack channel where lots of newcomers show up
to ask questions because they assume the OpenStack community relies
on Slack the same way the Kubernetes community does, and so a few
volunteers from our community hang out there and try to redirect
questions to more appropriate places. I've also heard tell of an
OpenStack subReddit which some stackers help moderate and try to
provide damage control/correct misstatements there. I don't think
these are necessarily a problem, and the members of our community
who work to spread accurate information to these places are in many
cases helping reduce the actual degree of fragmentation.

I'm still trying to make up my mind on 602697 which is why I haven't
weighed in on the proposal yet. So far I feel like it probably
doesn't bring anything new, since we already declare how and where
official discussion takes place and the measure doesn't make any
attempt to change that. We also don't regulate where unofficial
discussions are allowed to take place, and so it doesn't open up any
new possibilities which were previously disallowed.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

2018-09-18 Thread Jeremy Stanley
On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]
> I can understand that IRC cannot be used in China which is very
> painful and mostly it is used weChat.
[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election][tc]Question for candidates about global reachout

2018-09-18 Thread Jeremy Stanley
On 2018-09-18 10:23:33 +0800 (+0800), Zhipeng Huang wrote:
[...]
> Jeremy, what I'm saying here, and also addressed in comments with
> the related resolution patch, is that personality reasons are the
> ones that we have to respect and no form of governance change
> could help solve the problem. However other than that, we could
> always find a way to address the issue for remedies, if we don't
> have a good answer now maybe we will have sometime later.
> 
> Preference on  social tooling is something that the technical
> committee is able to address, with isolation of usage of
> proprietary tools for certain scenario and also strict policy on
> enforcing the open source communication solutions we have today as
> the central ones the community will continue to use. This is not
> an unsolvable problem given that we have a technical committee,
> but personality issues are, no matter what governance instrument
> we have.

Once again, I think we're talking past each other. I was replying to
(and quoted from) the provided sample rejection letter. First I
wanted to point out that I had already rejected the premise earlier
on this thread even though it was suggested that no rejection had
yet been provided. Second, the sample letter seemed to indicate what
I believe to be a fundamental misunderstanding among those pushing
this issue: the repeated attempts I've seen so far to paint a
disinterest in participating in wechat interactions as mere
"personal preference," and the idea that those who hold this
"preference" are somehow weak or afraid of the people they'll
encounter there.

For me, it borders on insulting. I (and I believe many others) have
strong ideological opposition to participating in these forums, not
mere personal preferences.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election][tc]Question for candidates about global reachout

2018-09-17 Thread Jeremy Stanley
On 2018-09-18 07:27:26 +0800 (+0800), Zhipeng Huang wrote:
[...]
> On another side note, there has not been a (maybe I missed) good
> "no" vote message I was looking for.
> 
> A good quality "no" message could something like this in my
> opinion (and this is just one of many possibilities):
> 
> "Thanks for invitation but no I would not like to use social media
> apps other than IRC. General social media apps are open to a more
> variety of people than in IRC channels and there are personalities
> or social characters that I found myself just cannot cope with.
> Moreover social media apps demands instant response, or at least
> has the expectation for one, in its nature and it would make me
> feel pressured all the time. So no thank you I would not use
> social media in any form, however if you do have good technical
> questions from the social apps, please feel free to relay to me
> and I'm glad to help when I have the bandwidth"

This seems to completely miss the reasons I personally reject such
platforms. I don't use proprietary tools or services for interacting
with our community, I avoid relying on products from companies which
attempt to track or share my location and activities for their own
profit or to report them to various government agencies, and I have
no interest in owning a "smart phone" (which some services such as
wechat outright require). At least for me, the example rejection you
proposed above is a miss on all counts...

I am plenty capable of coping with any of the "personalities or
social characters" I'm likely to encounter on those services (I'm
quite certain IRC is where you're going to find some of the worst
and *most* intolerable characters of any discussion medium). I also
am accustomed to providing a near instant response to urgent
requests in IRC, and at the same time don't feel particularly
"pressured" to do so. And I _do_ use some social media: both IRC and
mailing lists are in fact legitimate examples of social media. I'm
really not even opposed to using other forms as long as they rely on
open protocols and both the client _and_ server software are
available under a free/libre open source license.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election][tc]Question for candidates about global reachout

2018-09-17 Thread Jeremy Stanley
On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote:
[...]
> - What is the problem joining Wechat will solve (keeping in mind the
> language barrier)?

As I understand it, the suggestion is that mere presence of project
leadership in venues where this emerging subset of our community
gathers would provide a strong signal that we support them and care
about their experience with the software.

> - Isn't this problem already solved for other languages with
> existing initiatives like local ambassadors and i18n team? Why
> aren't these relevant?
[...]

It seems like there are at least couple of factors at play here:
first the significant number of users and contributors within
mainland China compared to other regions (analysis suggests there
were nearly as many contributors to the Rocky release from China as
the USA), but second there may be facets of Chinese culture which
make this sort of demonstrative presence a much stronger signal than
it would be in other cultures.

> - Pardon my ignorance here, what is the problem with email? (I
> understand some chat systems might be blocked, I thought emails
> would be fine, and the lowest common denominator).

Someone in the TC room (forgive me, I don't recall who now, maybe
Rico?) asserted that Chinese contributors generally only read the
first message in any given thread (perhaps just looking for possible
announcements?) and that if they _do_ attempt to read through some
of the longer threads they don't participate in them because the
discussion is presumed to be over and decisions final by the time
they "reach the end" (I guess not realizing that it's perfectly fine
to reply to a month-old discussion and try to help alter course on
things if you have an actual concern?).

> I also have technical questions about 'wechat' (like how do you
> use it without a smartphone?) and the relevance of tools we
> currently use, but this will open Pandora's box, and I'd rather
> not spend my energy on closing that box right now :D

Not that I was planning on running it myself, but I did look into
the logistics. Apparently there is at least one free/libre open
source wechat client under active development but you still need to
use a separate mobile device to authenticate your client's
connection to wechat's central communication service. By design, it
appears this is so that you can't avoid reporting your physical
location (it's been suggested this is to comply with government
requirements for tracking citizens participating in potentially
illegal discussions). They also go to lengths to prevent you from
running the required mobile app within an emulator, since that would
provide a possible workaround to avoid being tracked. Further, there
is some history of backdoors getting included in the software, so
you need to use it with the expectation that you're basically
handing over all communications and content for which you use that
mobile device to wechat developers/service operators and, by proxy,
the Chinese government.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election][tc]Question for candidates about global reachout

2018-09-14 Thread Jeremy Stanley
On 2018-09-14 13:52:50 -0600 (-0600), Zhipeng Huang wrote:
> This is a joint question from mnaser and me :)
> 
> For the candidates who are running for tc seats, please reply to
> this email to indicate if you are open to use certain social media
> app in certain region (like Wechat in China, Line in Japan, etc.),
> in order to reach out to the OpenStack developers in that region
> and help them to connect to the upstream community as well as
> answering questions or other activities that will help. (sorry for
> the long sentence ... )
[...]

I respect that tool choices can make a difference in enabling or
improving our outreach to specific cultures. I'll commit to
personally rejecting presence on proprietary social media services
so as to demonstrate that public work can be done within our
community while relying exclusively on free/libre open source
software. I recognize the existence of the free software movement as
a distinct culture with whom we could do a better job of connecting.
If as a community we promote and embrace non-free tools we will only
continue to alienate them, so I'm happy to serve as an example that
it is possible to be an engaged and effective contributor to our
community without compromising those ideals.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] Ongoing spam in Freenode IRC channels

2018-09-14 Thread Jeremy Stanley
On 2018-09-11 16:53:05 + (+), Jeremy Stanley wrote:
> On 2018-08-01 08:40:51 -0700 (-0700), James E. Blair wrote:
> > Monty Taylor  writes:
> > > On 08/01/2018 12:45 AM, Ian Wienand wrote:
> > > > I'd suggest to start, people with an interest in a channel can
> > > > request +r from an IRC admin in #openstack-infra and we track
> > > > it at [2]
> > >
> > > To mitigate the pain caused by +r - we have created a channel
> > > called #openstack-unregistered and have configured the channels
> > > with the +r flag to forward people to it.
> [...]
> > It turns out this was a very popular option, so we've gone ahead
> > and performed this for all channels registered with accessbot.
> [...]
> 
> We rolled this back 5 days ago for all channels and haven't had any
> new reports of in-channel spamming yet. Hopefully this means the
> recent flood is behind us now but definitely let us know (replying
> on this thread or in #openstack-infra on Freenode) if you see any
> signs of resurgence.

And then it was turned back on again a few hours ago after a new
wave of spam cropped up. We'll try to continue to keep an eye on
things.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-13 Thread Jeremy Stanley
On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote:
[...]
> Again, I'm not saying TC members should be doing all of the work
> themselves. That's not realistic, especially when critical parts
> of any major effort are going to involve developers from projects
> on which none of the TC members are active contributors (e.g.
> nova). I want to see TC members herd cats, for lack of a better
> analogy, and help out technically (with code) where possible.

I can respect that. I think that OpenStack made a mistake in naming
its community management governance body the "technical" committee.
I do agree that having TC members engage in activities with tangible
outcomes is preferable, and that the needs of the users of its
software should weigh heavily in prioritization decisions, but those
are not the only problems our community faces nor is it as if there
are no other responsibilities associated with being a TC member.

> Given the repeated mention of how the "help wanted" list continues
> to not draw in contributors, I think the recruiting role of the TC
> should take a back seat to actually stepping in and helping work
> on those items directly. For example, Sean McGinnis is taking an
> active role in the operators guide and other related docs that
> continue to be discussed at every face to face event since those
> docs were dropped from openstack-manuals (in Pike).

I completely agree that the help wanted list hasn't worked out well
in practice. It was based on requests from the board of directors to
provide some means of communicating to their business-focused
constituency where resources would be most useful to the project.
We've had a subsequent request to reorient it to be more like a set
of job descriptions along with clearer business use cases explaining
the benefit to them of contributing to these efforts. In my opinion
it's very much the responsibility of the TC to find ways to
accomplish these sorts of things as well.

> I think it's fair to say that the people generally elected to the
> TC are those most visible in the community (it's a popularity
> contest) and those people are generally the most visible because
> they have the luxury of working upstream the majority of their
> time. As such, it's their duty to oversee and spend time working
> on the hard cross-project technical deliverables that operators
> and users are asking for, rather than think of an infinite number
> of ways to try and draw *others* to help work on those gaps.

But not everyone who is funded for full-time involvement with the
community is necessarily "visible" in ways that make them electable.
Higher-profile involvement in such activities over time is what gets
them the visibility to be more easily elected to governance
positions via "popularity contest" mechanics.

> As I think it's the role of a PTL within a given project to have a
> finger on the pulse of the technical priorities of that project
> and manage the developers involved (of which the PTL certainly may
> be one), it's the role of the TC to do the same across openstack
> as a whole. If a PTL doesn't have the time or willingness to do
> that within their project, they shouldn't be the PTL. The same
> goes for TC members IMO.

Completely agree, I think we might just disagree on where to strike
the balance of purely technical priorities for the TC (as I
personally think the TC is somewhat incorrectly named).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Jeremy Stanley
On 2018-09-12 17:05:17 -0600 (-0600), Lance Bragstad wrote:
[...]
> IMHO, I think the point Matt is making here is more about ensuring
> sure we have people to do what we've agreed upon, as a community,
> as being mission critical. Enablement is imperative, but no matter
> how good we are at it, sometimes we really just needs hands to do
> the work.
[...]

Sure, and I'm saying that instead I think the influence of TC
members _can_ be more valuable in finding and helping additional
people to do these things rather than doing it all themselves, and
it's not just about the limited number of available hours in the day
for one person versus many. The successes goal champions experience,
the connections they make and the elevated reputation they gain
throughout the community during the process of these efforts builds
new leaders for us all.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Jeremy Stanley
On 2018-09-12 17:03:10 -0600 (-0600), Matt Riedemann wrote:
> On 9/12/2018 4:14 PM, Jeremy Stanley wrote:
> > I think Doug's work leading the Python 3 First effort is a great
> > example. He has helped find and enable several other goal champions
> > to collaborate on this. I appreciate the variety of other things
> > Doug already does with his available time and would rather he not
> > stop doing those things to spend all his time acting as a project
> > manager.
> 
> I specifically called out what Doug is doing as an example of
> things I want to see the TC doing. I want more/all TC members
> doing that.

With that I was replying to Zhipeng Huang's message which you have
trimmed above, specifically countering the assertion that recruiting
others to help with these efforts is a waste of time and that TC
members should simply do all the work themselves instead.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Jeremy Stanley
On 2018-09-12 16:03:12 -0600 (-0600), Zhipeng Huang wrote:
> On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley  wrote:
> > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
> > [...]
> > > So I encourage all elected TC members to work directly with the
> > > various SIGs to figure out their top issue and then work on
> > > managing those deliverables across the community because the TC is
> > > particularly well suited to do so given the elected position.
> > [...]
> >
> > I almost agree with you. I think the OpenStack TC members should be
> > actively engaged in recruiting and enabling interested people in the
> > community to do those things, but I don't think such work should be
> > solely the domain of the TC and would hate to give the impression
> > that you must be on the TC to have such an impact.
> 
> Jeremy, this is not to say that one must be on the TC to have such an
> impact, it is that TC has the duty more than anyone else to get this
> specific cross-project goal done. I would even argue it is not the job
> description of TC to enable/recruit, but to just do it.

I think Doug's work leading the Python 3 First effort is a great
example. He has helped find and enable several other goal champions
to collaborate on this. I appreciate the variety of other things
Doug already does with his available time and would rather he not
stop doing those things to spend all his time acting as a project
manager.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)

2018-09-12 Thread Jeremy Stanley
On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote:
[...]
> So I encourage all elected TC members to work directly with the
> various SIGs to figure out their top issue and then work on
> managing those deliverables across the community because the TC is
> particularly well suited to do so given the elected position.
[...]

I almost agree with you. I think the OpenStack TC members should be
actively engaged in recruiting and enabling interested people in the
community to do those things, but I don't think such work should be
solely the domain of the TC and would hate to give the impression
that you must be on the TC to have such an impact.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] Ongoing spam in Freenode IRC channels

2018-09-11 Thread Jeremy Stanley
On 2018-08-01 08:40:51 -0700 (-0700), James E. Blair wrote:
> Monty Taylor  writes:
> > On 08/01/2018 12:45 AM, Ian Wienand wrote:
> > > I'd suggest to start, people with an interest in a channel can
> > > request +r from an IRC admin in #openstack-infra and we track
> > > it at [2]
> >
> > To mitigate the pain caused by +r - we have created a channel
> > called #openstack-unregistered and have configured the channels
> > with the +r flag to forward people to it.
[...]
> It turns out this was a very popular option, so we've gone ahead
> and performed this for all channels registered with accessbot.
[...]

We rolled this back 5 days ago for all channels and haven't had any
new reports of in-channel spamming yet. Hopefully this means the
recent flood is behind us now but definitely let us know (replying
on this thread or in #openstack-infra on Freenode) if you see any
signs of resurgence.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things

2018-09-10 Thread Jeremy Stanley
On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote:
[...]
> # Linking to projects by name
> 
> Keen observers might've noticed that StoryBoard recently grew the ability
> to link to projects by name, rather than by ID number. All the links to
> projects in the UI have been replaced with links in this form, and its
> probably a good idea for folk to start using them in any documentation
> they have. These links look like
> 
>   https://storyboard.openstack.org/#!/project/openstack-infra/storyboard
[...]

Worth noting, this has made it harder to find the numeric project ID
without falling back on the API. Change
https://review.openstack.org/600893 merged to the releases
repository yesterday allowing deliverable repositories to be
referenced by their StoryBoard project name rather than only the ID
number. If there are other places in tooling and automation where we
relied on the project ID number, work should be done to update those
similarly.

> # Finding stories from a task ID
> 
> It is now possible to navigate to a story given just a task ID, if for
> whatever reason that's all the information you have available. A link like
> 
>   https://storyboard.openstack.org/#!/task/12389
> 
> will work. This will redirect to the story containing the task, and is the
> first part of work to support linking directly to an individual task in a
> story.
[...]

As an aside, I think this makes it possible now for us to start
hyperlinking Task footers in commit messages within the Gerrit
change view. I'll try and figure out what we need to adjust in our
Gerrit commentlink and its-storyboard plugin configs to make that
happen.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election][tc] Opinion about 'PTL' tooling

2018-09-10 Thread Jeremy Stanley
On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote:
> I think something we should take into consideration is *what* you
> consider health because the way we’ve gone about it over health
> checks is not something that can become a toolkit because it was
> more of question asking, etc
[...]

I was going to follow up with something similar. It's not as if the
TC has a toolkit of any sort at this point to come up with the
information we're assembling in the health tracker either. It's
built up from interviewing PTLs, reading meeting logs, looking at
the changes which merge to teams' various deliverable repositories,
asking around as to whether they've missed important deadlines such
as release milestones (depending on what release models they
follow) or PTL nominations, looking over cycle goals to see how far
along they are, and so on. Extremely time-consuming which is why
it's taken us most of a release cycle and we still haven't finished
a first pass.

Assembling some of this information might be automatable if we make
adjustments to how the data/processes on which it's based are
maintained, but at this point we're not even sure which ones are
problem indicators at all and are just trying to provide the
clearest picture we can. If we come up with a detailed checklist and
some of the checks on that list can be automated in some way, that
seems like a good thing. However, the original data should be
publicly accessible so I don't see why it needs to be members of the
technical committee who write the software to collect that.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Storyboard][Searchlight] Where can I find the project ID on Storyboard?

2018-09-07 Thread Jeremy Stanley
On 2018-09-08 10:10:37 +0900 (+0900), Trinh Nguyen wrote:
> I'm adding Searchlight projects to the Stein deliverables with the
> storyboard attribute. Where can I find the Searchlight projects ID? Right
> now I can only see the project links.

It can be looked up from the API like so:

https://storyboard.openstack.org/api/v1/projects/openstack/searchlight

However I agree expecting users to do this isn't particularly
friendly. Since this was in service of filling out release
management details, I've pushed https://review.openstack.org/600893
for review to support optionally using the project name now that SB
supports querying with it and uses it by default in webclient URLs.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] OpenStack Summit Forum in Berlin: Topic Selection Process

2018-09-06 Thread Jeremy Stanley
On 2018-09-06 15:03:52 -0500 (-0500), Matt Riedemann wrote:
> On 9/6/2018 2:56 PM, Jeremy Stanley wrote:
> > On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:
> > > On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
> > > > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur  > > > <mailto:ji...@openstack.org>> wrote:
> > > > 
> > > > 
> > > >  Examples of typical sessions that make for a great Forum:
> > > > 
> > > >  Strategic, whole-of-community discussions, to think about the big
> > > >  picture, including beyond just one release cycle and new 
> > > > technologies
> > > > 
> > > >  e.g. OpenStack One Platform for containers/VMs/Bare Metal 
> > > > (Strategic
> > > >  session) the entire community congregates to share opinions on how
> > > >  to make OpenStack achieve its integration engine goal
> > > > 
> > > > 
> > > > Just to clarify some speculation going on in IRC: this is an example,
> > > > right? Not a new thing being announced?
> > > > 
> > > > // jim
> > > FYI for those that didn't see this on the other ML:
> > > 
> > > http://lists.openstack.org/pipermail/foundation/2018-August/002617.html
> > [...]
> > 
> > While I agree that's a great post to point out to all corners of the
> > community, I don't see what it has to do with whether "OpenStack One
> > Platform for containers/VMs/Bare Metal" was an example forum topic.
> 
> Because if I'm not mistaken it was the impetus for the hullabaloo in the tc
> channel that was related to the foundation ML post.

It would be more accurate to say that community surprise over the
StarlingX mention in Vancouver keynotes caused some people to
(either actually or merely in half-jest) start looking for subtext
everywhere indicating the next big surprise announcement. The
discussion[*] in #openstack-tc readily acknowledged that most of its
participants didn't think "OpenStack One Platform for
containers/VMs/Bare Metal" was an actual proposal for a forum
discussion much less announcement of a new project, but were just
looking for an opportunity to show feigned alarm and sarcasm.

The most recent discussion[**] leading up to the foundation ML "OSF
Open Infrastructure Projects" update occurred the previous week.
That E-mail did go out the day after the forum topic brainstorming
example discussion, but was unrelated (and already in the process of
being put together by then).

[*] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-29.log.html#t2018-08-29T16:55:37
[**] 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-23.log.html#t2018-08-23T16:23:00
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] OpenStack Summit Forum in Berlin: Topic Selection Process

2018-09-06 Thread Jeremy Stanley
On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote:
> On 8/29/2018 1:08 PM, Jim Rollenhagen wrote:
> > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur  > <mailto:ji...@openstack.org>> wrote:
> > 
> > 
> > Examples of typical sessions that make for a great Forum:
> > 
> > Strategic, whole-of-community discussions, to think about the big
> > picture, including beyond just one release cycle and new technologies
> > 
> > e.g. OpenStack One Platform for containers/VMs/Bare Metal (Strategic
> > session) the entire community congregates to share opinions on how
> > to make OpenStack achieve its integration engine goal
> > 
> > 
> > Just to clarify some speculation going on in IRC: this is an example,
> > right? Not a new thing being announced?
> > 
> > // jim
> 
> FYI for those that didn't see this on the other ML:
> 
> http://lists.openstack.org/pipermail/foundation/2018-August/002617.html
[...]

While I agree that's a great post to point out to all corners of the
community, I don't see what it has to do with whether "OpenStack One
Platform for containers/VMs/Bare Metal" was an example forum topic.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [OpenStack-I18n] [storyboard] [I18n] Can Storyboard web pages be translatable to multiple languages?

2018-09-06 Thread Jeremy Stanley
On 2018-09-06 11:06:34 +0900 (+0900), Ian Y. Choi wrote:
> I wanna ask whether https://storyboard.openstack.org/ web pages
> can be translatable to multiple languages (e.g., Chinese,
> Japanese, Korean, German, French, Spanish, ...) or not.
[...]

As also discussed in #storyboard I think this is an interesting
idea, particularly for organizations who may want to use StoryBoard
deployments where most users are fluent in one of those other
languages (and perhaps not at all with English).

I do think interface translation is potentially useful for the
OpenStack community's storyboard.openstack.org service too, though
we'll want to keep in mind that for most of the projects hosted
there English is explicitly preferred to increase collaboration
(same as with most OpenStack community mailing lists, IRC channels,
code review and so on). We may discover that we need to find ways to
point out to people, particularly those arriving there for the first
time, that they should file stories in English if at all possible
even though the interface may be presented in their personally
preferred language instead.

I've added this topic to
https://etherpad.openstack.org/p/sb-stein-ptg-planning and am
looking forward to seeing you in Denver!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Storyboard][Searchlight] Commits of searchlight-specs are not attached to the story

2018-09-06 Thread Jeremy Stanley
On 2018-09-06 16:39:13 +0900 (+0900), Trinh Nguyen wrote:
> Looks like the commits for searchlight-specs are not attached to
> the story on Storyboard. Example:
> 
> Commit: https://review.openstack.org/#/c/600316/
> Story: https://storyboard.openstack.org/#!/story/2003677
> 
> Is there anything that I need to do to link those 2 together?

In change 600316 you included a "Task: #2619" footer, when the
actual task you seem to have wanted to reference was 26199 (task
2619 is associated with unrelated story 2000403).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] better name for placement

2018-09-05 Thread Jeremy Stanley
On 2018-09-05 17:01:49 +0200 (+0200), Thomas Goirand wrote:
[...]
> In a distro, no 2 package can hold the same file. That's
> forbidden. This has nothing to do if someone has to "import
> placemement" or not.
> 
> Just saying this, but *not* that we should rename (I didn't spot
> any conflict yet and I understand the pain it would induce). This
> command returns nothing:
> 
> apt-file search placement | grep python3/dist-packages/placement

Well, also since the Placement maintainers have expressed that they
aren't interested in making Python API contracts for it to be usable
as an importable library, there's probably no need to install its
modules into the global Python search path anyway. They could just
go into a private module path on the filesystem instead as long as
the placement service/entrypoint wrapper knows where to find them,
right?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [election] [tc] thank you

2018-09-05 Thread Jeremy Stanley
On 2018-09-04 22:11:41 -0400 (-0400), Emilien Macchi wrote:
> After 2 years at the TC, I feel lucky enough to have been part of this
> group where I hope that my modest contributions helped to make OpenStack a
> bit better.
[...]

I think they have. I've always valued your input, and hope you
continue providing it whether or not you're serving on the TC.
Thanks, really!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] non-candidacy for TC

2018-09-04 Thread Jeremy Stanley
On 2018-09-04 19:46:30 -0400 (-0400), Paul Belanger wrote:
> After a year on the TC, I've decided not to run for another term.
[...]

Thank you for your service (past and future)!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] Run for a seat on the TC (I am, and you can too!)

2018-09-04 Thread Jeremy Stanley
I'm standing for reelection to a third term on the OpenStack
Technical Committee. Rather than the usual platform where I drone on
and on about myself, I'm going to take this opportunity to run a
public service announcement instead.

Going into my second term I stated, "my personal vision for
OpenStack is that of a vibrant and diverse community" and I think
we've made progress on that front but still have a long way to go.
The diversity (personal, professional and cultural) of our community
has increased steadily, but we won't be able to sustain it if
similar diversity among elected leaders continues to lag behind. Our
leaders are frequently the faces of our community to those outside
it, and should set an example for others to follow. OpenStack is
built on a promise of representative leadership, and so we need
people from under-represented segments of our community to stand and
take up the challenge. There's just over 48 hours left to send in
your self-nomination for a seat on the TC. If you can't meet the
time commitments but know someone who can, encourage them to run.

And, of course, when the time comes, vote. Vote for the candidates
who best represent you, your beliefs, your ideals. Vote for those
who share your vision for who, how and what OpenStack should be. If
you've been paying attention these past years, you already know my
opinions. I'd rather hear some new opinions from you.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] better name for placement

2018-09-04 Thread Jeremy Stanley
On 2018-09-04 11:44:41 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100:
[...]
> > I would hope we'd be able to do that, and probably should do that.
> > 'openstack-placement' seems a find pypi package name for a think
> > from which you do 'import placement' to do some openstack stuff,
> > yeah?
> 
> That's still a pretty generic name for the top-level import, but I think
> the only real risk is that the placement service couldn't be installed
> at the same time as another package owned by someone else that used that
> top-level name. I'm not sure how much of a risk that really is.
[...]

Well, it goes further than just the local system. For example, if
there was another project unrelated to OpenStack which also had a
module named "placement" in the default import path, then Debian
wouldn't be able to carry packages for both projects without
modifying. At least one would need the module renamed or would need
to put it in a private path and then any consumers would need to be
adjusted to suit.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] better name for placement (was:Nominating Chris Dent for placement-core)

2018-09-04 Thread Jeremy Stanley
On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote:
[...]
> it allowed for the possibility that there could be another project
> which provided the same service-type. That hasn't really come to
> pass
[...]

It still might make sense to attempt to look at this issue from
outside the limited scope of the OpenStack community. Is the
expectation that the project when packaged (on PyPI, in Linux
distributions and so on) will just be referred to as "placement"
with no further context?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] Bringing the community together (combine the lists!)

2018-08-31 Thread Jeremy Stanley
On 2018-08-31 14:02:23 +0200 (+0200), Thomas Goirand wrote:
[...]
> I'm coming from the time when OpenStack had a list on launchpad
> where everything was mixed. We did the split because it was really
> annoying to have everything mixed.
[...]

These days (just running stats for this calendar year) we've been
averaging 4 messages a day on the general openstack@lists.o.o ML, so
if it's volume you're worried about most of it would be the current
-operators and -dev ML discussions anyway (many of which are general
questions from users already, because as you also pointed out we
don't usually tell them to take their questions elsewhere any more).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] Mailman topic filtering (was: Bringing the community together...)

2018-08-31 Thread Jeremy Stanley
On 2018-08-31 09:35:55 +0100 (+0100), Stephen Finucane wrote:
[...]
> I've tinked with mailman 3 before so I could probably take a shot at
> this over the next few week(end)s; however, I've no idea how this
> feature is supposed to work. Any chance an admin of the current list
> could send me a couple of screenshots of the feature in mailman 2 along
> with a brief description of the feature? Alternatively, maybe we could
> upload them to the wiki page Tony linked above or, better yet, to the
> technical details page for same:
> 
>   https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details

Looks like this should be
https://wiki.list.org/DEV/Brief%20Technical%20Details instead,
however reading through it doesn't really sound like the topic
filtering feature from MM2.

The List Member Manual has a very brief description of the feature
from the subscriber standpoint:

http://www.list.org/mailman-member/node29.html

The List Administration Manual unfortunately doesn't have any
content for the feature, just a stubbed-out section heading:

http://www.list.org/mailman-admin/node30.html

Sending screenshots to the ML is a bit tough, but luckily MIT's
listadmins have posted some so we don't need to:

http://web.mit.edu/lists/mailman/topics.html

-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] [Openstack-operators] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Jeremy Stanley
On 2018-08-30 18:08:56 -0500 (-0500), Melvin Hillsman wrote:
[...]
> I also recall us discussing having some documentation or way of
> notifying net new signups of how to interact with the ML
> successfully. An example was having some general guidelines around
> tagging. Also as a maintainer for at least one of the mailing
> lists over the past 6+ months I have to inquire about how that
> will happen going forward which again could be part of this
> documentation/initial message.
[...]

Mailman supports customizable welcome messages for new subscribers,
so the *technical* implementation there is easy. I do think (and
failed to highlight it explicitly earlier I'm afraid) that this
proposal comes with an expectation that we provide recommended
guidelines for mailing list use/etiquette appropriate to our
community. It could be contained entirely within the welcome
message, or merely linked to a published document (and whether
that's best suited for the Infra Manual or New Contributor Guide or
somewhere else entirely is certainly up for debate), or even
potentially both.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-operators] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Jeremy Stanley
On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
[...]
> I really don't want this. I'm happy with things being sorted in
> multiple lists, even though I'm subscribed to multiples.

I understand where you're coming from, and I used to feel similarly.
I was accustomed to communities where developers had one mailing
list, users had another, and whenever a user asked a question on the
developer mailing list they were told to go away and bother the user
mailing list instead (not even a good, old-fashioned "RTFM" for
their trouble). You're probably intimately familiar with at least
one of these communities. ;)

As the years went by, it's become apparent to me that this is
actually an antisocial behavior pattern, and actively harmful to the
user base. I believe OpenStack actually wants users to see the
development work which is underway, come to understand it, and
become part of that process. Requiring them to have their
conversations elsewhere sends the opposite message.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Jeremy Stanley
On 2018-08-30 12:57:31 -0600 (-0600), Chris Friesen wrote:
[...]
> Do we want to merge usage and development onto one list? That
> could be a busy list for someone who's just asking a simple usage
> question.

A counterargument though... projecting the number of unique posts to
all four lists combined for this year (both based on trending for
the past several years and also simply scaling the count of messages
this year so far based on how many days are left) comes out roughly
equal to the number of posts which were made to the general
openstack mailing list in 2012.

> Alternately, if we are going to merge everything then why not just
> use the "openstack" mailing list since it already exists and there
> are references to it on the web.

This was an option we discussed in the "One Community" forum session
as well. There seemed to be a slight preference for making a new
-disscuss list and retiring the old general one. I see either as an
potential solution here.

> (Or do you want to force people to move to something new to make them
> recognize that something has changed?)

That was one of the arguments made. Also I believe we have a *lot*
of "black hole" subscribers who aren't actually following that list
but whose addresses aren't bouncing new posts we send them for any
of a number of possible reasons.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Jeremy Stanley
On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote:
[...]
> What needs to be done for this is full topic categories support
> under `options` page so people get to filter emails properly.
[...]

Unfortunately, topic filtering is one of the MM2 features the
Mailman community decided nobody used (or at least not enough to
warrant preserving it in MM3). I do think we need to be consistent
about tagging subjects to make client-side filtering more effective
for people who want that, but if we _do_ want to be able to upgrade
we shouldn't continue to rely on server-side filtering support in
Mailman unless we can somehow work with them to help in
reimplementing it.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [all] Bringing the community together (combine the lists!)

2018-08-30 Thread Jeremy Stanley
The openstack, openstack-dev, openstack-sigs and openstack-operators
mailing lists on lists.openstack.org see an increasing amount of
cross-posting and thread fragmentation as conversants attempt to
reach various corners of our community with topics of interest to
one or more (and sometimes all) of those overlapping groups of
subscribers. For some time we've been discussing and trying ways to
bring our developers, distributors, operators and end users together
into a less isolated, more cohesive community. An option which keeps
coming up is to combine these different but overlapping mailing
lists into one single discussion list. As we covered[1] in Vancouver
at the last Forum there are a lot of potential up-sides:

1. People with questions are no longer asking them in a different
place than many of the people who have the answers to those
questions (the "not for usage questions" in the openstack-dev ML
title only serves to drive the wedge between developers and users
deeper).

2. The openstack-sigs mailing list hasn't seem much uptake (an order
of magnitude fewer subscribers and posts) compared to the other
three lists, yet it was intended to bridge the communication gap
between them; combining those lists would have been a better
solution to the problem than adding yet another turned out to be.

3. At least one out of every ten messages to any of these lists is
cross-posted to one or more of the others, because we have topics
that span across these divided groups yet nobody is quite sure which
one is the best venue for them; combining would eliminate the
fragmented/duplicative/divergent discussion which results from
participants following up on the different subsets of lists to which
they're subscribed,

4. Half of the people who are actively posting to at least one of
the four lists subscribe to two or more, and a quarter to three if
not all four; they would no longer be receiving multiple copies of
the various cross-posts if these lists were combined.

The proposal is simple: create a new openstack-discuss mailing list
to cover all the above sorts of discussion and stop using the other
four. As the OpenStack ecosystem continues to mature and its
software and services stabilize, the nature of our discourse is
changing (becoming increasingly focused with fewer heated debates,
distilling to a more manageable volume), so this option is looking
much more attractive than in the past. That's not to say it's quiet
(we're looking at roughly 40 messages a day across them on average,
after deduplicating the cross-posts), but we've grown accustomed to
tagging the subjects of these messages to make it easier for other
participants to quickly filter topics which are relevant to them and
so would want a good set of guidelines on how to do so for the
combined list (a suggested set is already being brainstormed[2]).
None of this is set in stone of course, and I expect a lot of
continued discussion across these lists (oh, the irony) while we try
to settle on a plan, so definitely please follow up with your
questions, concerns, ideas, et cetera.

As an aside, some of you have probably also seen me talking about
experiments I've been doing with Mailman 3... I'm hoping new
features in its Hyperkitty and Postorius WebUIs make some of this
easier or more accessible to casual participants (particularly in
light of the combined list scenario), but none of the plan above
hinges on MM3 and should be entirely doable with the MM2 version
we're currently using.

Also, in case you were wondering, no the irony of cross-posting this
message to four mailing lists is not lost on me. ;)

[1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community
[2] https://etherpad.openstack.org/p/common-openstack-ml-topics
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread Jeremy Stanley
On 2018-08-28 10:11:18 -0700 (-0700), John Dickinson wrote:
[...]
> It would be *really* helpful to have a simple rule or pattern for
> each file's header. Something like "Copyright (c)  created>-present by contributors to this project".

I applaud and share your desire for a clear rule on such things.
Sadly, I have serious doubts it's possible to get one.

> As you mentioned, this issue comes up about every two years, and having
> contributors police (via code review) the appropriate headers for every
> commit is not a sustainable pattern. The only thing I'm sure about is that
> the existing copyright headers are not correct, but I have no idea what the
> correct header are.

The point was not really for reviewers (who can't necessarily know
whether or not a copyright claim is in any way legitimate), but
rather for authors (please don't assign copyright of your works to
the OSF).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread Jeremy Stanley
[Obligatory disclaimer: I am not a lawyer, this is not legal advice,
and I am not representing the OpenStack Foundation in any legal
capacity here.]

TL;DR: You should not be putting "Copyright OpenStack Foundation" on
content in Git repositories, or anywhere else for that matter
(unless you know that you are actually an employee of the OSF or
otherwise performing work-for-hire activities at the behest of the
OSF). The OpenStack Individual Contributor License Agreement (ICLA)
does not require copyright assignment. The foundation does not want,
nor does it even generally accept, copyright assignment from
developers. Your copyrightable contributions are your own, or by
proxy are the copyright of your employer if you have created them as
a part of any work-for-hire arrangement (unless you've negotiated
with your employer to retain copyright of your work).

This topic has been raised multiple times in the past. In the wake
of a somewhat protracted thread on the
legal-disc...@lists.openstack.org mailing list (it actually started
out on the openstack-dev mailing list but was then redirected to a
more appropriate venue) back in April, 2013, we attempted to record
a summary in the wiki article we'd been maintaining regarding
various frequently-asked legal questions:
https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers

In the intervening years, we've worked to make sure other important
documentation moves out of the wiki and into more durable
maintenance (mostly Git repositories under code review, rendered and
published to a Web site). I propose that as this particular topic is
germane to contributing to the development of OpenStack software,
the OpenStack Technical Committee should publish a statement on the
governance site similar in nature to or perhaps as an expansion of
the https://governance.openstack.org/tc/reference/licensing.html
page where we detail copyright licensing expectations for official
OpenStack project team deliverables. As I look back through that
wiki article, I see a few other sections which may also be
appropriate to cover on the governance site.

The reason I'm re-raising this age-old discussion is because change
https://review.openstack.org/596619 came to my attention a few
minutes ago, in which some 400+ files within the
openstack/openstack-helm repository were updated to assign copyright
to "OpenStack Foundation" based on this discussion from an
openstack-helm IRC meeting back in March (which seems to have
involved no legal representative of the OSF):
http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101

There are also a couple of similar changes under the same review
topic for the openstack/openstack-helm-infra and
openstack/openstack-helm-addons repositories, one of which I managed
to -1 before it could be approved and merged. I don't recall any
follow-up discussion on the legal-disc...@lists.openstack.org or
even openstack-dev@lists.openstack.org mailing lists, which I would
have expected for any change of this legal significance.

The point of this message is of course not to berate anyone, but to
raise the example which seems to indicate that as a community we've
apparently not done a great job of communicating the legal aspects
of contributing to OpenStack. If there are no objections, I'll push
up a proposed addition to the openstack/governance repository
addressing this semi-frequent misconception and follow up with a
link to the review. I'm also going to post to the legal-discuss ML
so as to make the subscribers there aware of this thread.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [oslo] UUID sentinel needs a home

2018-08-24 Thread Jeremy Stanley
On 2018-08-24 18:51:08 -0500 (-0500), Matt Riedemann wrote:
[...]
> So just follow me here people, what if we had this common shared
> library where code could incubate and then we could write some
> tools to easily copy that common code into other projects...

If we do this, can we at least put it in a consistent place in all
projects? Maybe name the directory something like "openstack/common"
just to make it obvious.

> I'm pretty sure I could get said project approved as a top-level
> program under The Foundation and might even get a talk or two out
> of this idea. I can see the Intel money rolling in now...

Seems like a sound idea. Can we call it "Nostalgia" for no
particular reason? Though maybe "Recurring Nightmare" would be a
more accurate choice.
-- 
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-22 Thread Jeremy Stanley
On 2018-08-22 00:17:41 + (+), Fox, Kevin M wrote:
> There have been plenty of cross project goals set forth from the
> TC and implemented by the various projects such as wsgi or
> python3. Those have been worked on by each of the projects in
> priority to some project specific goals by devs interested in
> bettering OpenStack. Why is it so hard to believe if the TC gave
> out a request for a grander user/ops supporting feature, that the
> community wouldn't step up? PTL's are supposed to be neutral to
> vendor specific issues and work for the betterment of the Project.

Those goals, cross-project by nature, necessarily involve people
with domain-specific knowledge in the requisite projects. That is a
lot different than expecting Cinder developers to switch gears and
start working on Barbican instead just because the TC (or the UC, or
the OSF BoD, or whoever) decrees key management is prioritized over
multi-attach storage. Cross-project goal setting is already a
strained process, in which we as a community spend a _lot_ of time
and effort to determine what various project teams are even willing
to work on and prioritize alongside the things they already get
done. Asking them to work on something has absolutely not stopped
them from wanting to work on other things instead.

There are plenty of instances where the community (via its elected
leadership) has attempted to set goals and some teams have chosen to
work on other priorities of their own instead. If they could have
directed all their contributors to focus on that it would have been
completed, but they (all teams really) attempt balance the
priorities set by the OpenStack Technical Committee and other
leadership with their own project-specific priorities. Just as the
TC sinks a lot of effort into getting teams to focus on things it
identifies as priorities, the PTLs encounter similar challenges
getting their teams to focus on whatever priorities they've set as a
group. Some contributors only work on what interests them, some only
on what their employer tells them, and so on, while much of the rest
struggle simply to keep up with the overall rate of change.

> I don't buy the complexity argument either. Other non OpenStack
> projects are implementing similar functionality with far less
> complexity. I attribute a lot of that to difference in governence.
> Through governence we've made hard things much harder. They can't
> be fixed until the governence issues are fixed first I think.
[...]

Again, specifics would be nice. What decisions has the community
made in governing itself which have contributed to the problems you
see? What incremental changes would you make to improve that
situation (hint: blow-it-all-up suggestions like "get rid of PTLs"
aren't solutions when you're steering a community consisting of
thousands of developers, we need steps to get from point A to point
B)? In this _particular_ situation, what action are you asking the
TC or other community leaders to take to resolve the problem (and
what do you see as "the problem" in this case, for that matter)?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-22 Thread Jeremy Stanley
On 2018-08-22 11:03:43 -0700 (-0700), melanie witt wrote:
[...]
> I think it's about context. If two separate projects do their own priority
> and goal setting, separately, I think they will naturally be more different
> than they would be if they were one project. Currently, we agree on goals
> and priorities together, in the compute context. If placement has its own
> separate context, the priority setting and goal planning will be done in the
> context of placement. In two separate groups, someone who is a member of
> both the Nova and Placement teams would have to persuade Placement-only
> members to agree to prioritize a particular item. This may sound subtle, but
> it's a notable difference in how things work when it's one team vs two
> separate teams. I think having shared context and alignment, at this point
> in time, when we have outstanding closely coupled nova/placement work to do,
> is critical in delivering for operators and users who are depending on us.
[...]

I'm clearly missing some critical detail about the relationships in
the Nova team. Don't the Nova+Placement contributors already have to
convince the Placement-only contributors what to prioritize working
on? Or are you saying that if they disagree that's fine because the
Nova+Placement contributors will get along just fine without the
Placement-only contributors helping them get it done?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley
On 2018-08-21 22:42:45 + (+), Fox, Kevin M wrote:
[...]
> Yes, I realize shared storage was Cinders priority and Nova's now
> way behind in implementing it. so it is kind of a priority to get
> it done. Just using it as an example though in the bigger context.
> 
> Having operators approach individual projects stating their needs,
> and then having the individual projects fight it out for
> priorities isn't a good plan. The priorities should be prioritized
> at a higher level then projects so the operators/users needs can
> be seen in a global light, not just filtered though each projects
> views of things.
> 
> Yes, some folks volunteer to work on the things that they want to
> work on. Thats great. But some folks volunteer to work on
> priorities to help users/operators in general. Getting clear,
> unbiased priorities for them is really important.
[...]

I remain unconvinced that if someone (the TC, the OSF board, the now
defunct product management nee hidden influencers working group)
declared for example that secrets management was a higher priority
than shared storage, that any significant number of people who could
work on the latter would work on the former instead.

The TC has enough trouble getting developers in different projects
to cooperate on more than a couple of prioritized cross-project
goals per cycle. The OSF board has repeatedly shown its members are
rarely in the positions within member companies that they have any
influence over what upstream features/projects those companies work
on. The product management working group thought they had that
influence over the companies in which they worked, but were
similarly unable to find developers who could make progress toward
their identified goals.

OpenStack is an extremely complex (arguably too complex) combination
of software, for which there are necessarily people with very strong
understanding of very specific pieces and at best a loose
understanding of the whole. In contrast, there are few people who
have both the background and interest (much less leeway from their
employers in the case of paid contributors) to work on any random
feature of any random project and be quickly effective at it. If
you're familiar with, say, Linux kernel development, you see very
much the same sort of specialization with developers who are
familiar with specific kernel subsystems and vanishingly few who can
efficiently (that is to say without investing lots of time to come
up to speed) implement novel features in multiple unrelated
subsystems.

We'll all continue to work on get better at this, but hard things
are... well... hard.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley
On 2018-08-21 17:18:40 + (+), Fox, Kevin M wrote:
[...]
> I'm really sure at this point that you can't have a project as
> large as OpenStack without leadership setting a course and
> sometimes making hard choices for the betterment of the whole.
> That doesn't mean a benevolent dictator. But our self govened
> model with elected officials should be a good balance. If they are
> too unreasonable, they don't get reelected. But not leading isn't
> an option either anymore.
[...]

Divining a consensual direction in which to steer the community is
not the same thing as telling people what to do, but is still very
much leadership. But I'd rather stop dancing in generalities and
just talk about concrete examples instead. In this case, separation
of governance between Nova and (as of yet unnamed) placement teams.

If the Nova team is against wholly handing over control of the
placement service to the current placement contributors, then having
the OpenStack Technical Committee tell them to get over it isn't the
way to foster productive future relationships between those two
groups of people. The placement team is already entirely empowered,
should they wish, to fork the placement service out of the nova
repository and then apply to the TC to have that recognized as a
separate team but doing so in no way guarantees the Nova team will
work with them to use that version of placement and deprecate the
one on which they currently rely. For that, there needs to be a
positive working relationship, one we can't simply demand into
being, so it's in their best interests to work things out amicably
and directly instead of asking someone else (the TC) to decide this
for them.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley
On 2018-08-21 16:38:41 + (+), Fox, Kevin M wrote:
[...]
> You need someone like the TC to be able to step in, in those cases
> to help sort that kind of issue out. In the past, the TC was not
> willing to do so. My gut feeling though is that is finally
> changing.
[...]

To be clear, it's not that TC members are unwilling to step into
these discussions. Rather, it's that most times when a governing
body has to tell volunteers to do something they don't want to do,
it tends to not be particularly helpful in solving the underlying
disagreement.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Jeremy Stanley
On 2018-08-20 14:25:06 -0400 (-0400), Zane Bitter wrote:
> On 20/08/18 14:02, Chris Friesen wrote:
> > In order to address the "velocity of change in placement"
> > issues, how about making the main placement folks members of
> > nova-core with the understanding that those powers would only be
> > used in the new placement repo?
> 
> That kind of 'understanding' is only needed (because of
> limitations in Gerrit) when working in the same repo. Once it's in
> a separate repo you just create a new 'placement-core' group and
> make nova-core a member of it.

More correctly, the effort you'd go through to correctly
characterize subsets of a repository under control of different
groups of people is within the same order of magnitude as just
putting them in separate Git repositories (especially when you take
in to consideration the knock-on effects of duplicating things like
review dashboards for the various prolog rules defined for those
different subsets of the repository). If you're going to attempt to
delegate review on portions of a Git repository, in most cases you
may as well go ahead and make it a separate repository anyway.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

2018-08-16 Thread Jeremy Stanley
On 2018-08-17 06:56:11 +1000 (+1000), Tony Breeds wrote:
[...]
> How terrible would it be to branch openstackdocstheme and backport
> the fix without the pbr changes?  It might also be possible,
> though I'm not sure how we'd land it, to branch (stable/ocata)
> openstackdocstheme today and just revert the pbr changes to set
> the lower bound.
[...]

I think it would also be entirely reasonable to just not worry about
it, and let the people who asked for extended maintenance on older
branches do the legwork. We previously limited the number we'd keep
open because keeping those older branches updatable does in fact
require quite a bit of effort. When we agreed to the suggestion of
not closing branches, it was with the understanding that they won't
just suddenly get taken care of by the same people who were already
not doing that because they considered it a lot of extra work.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [all] Personal tool patterns in .gitignore cookiecutter

2018-08-16 Thread Jeremy Stanley
In response to some recent but misguided proposals from well-meaning
contributors in various projects, I've submitted a change[*] for the
openstack-dev/cookiecutter .gitignore template inserting a comment
which recommends against including patterns related to personal
choices of tooling (arbitrary editors, IDEs, operating systems...).
It includes one suggestion for a popular alternative (creating a
personal excludesfile specific to the tools you use), but there are
of course multiple ways it can be solved.

This is not an attempt to set policy, but merely provides a
recommended default for new repositories in hopes that projects can
over time reduce some of the noise related to unwanted .gitignore
additions. If it merges, projects who disagree with this default can
of course modify or remove the comment at the top of the file as
they see fit when bootstrapping content for a new repository.
Projects with existing repositories on which they'd like to apply
this can also easily copy the comment text or port the patch.

If there seems to be some consensus that this change is appreciated,
I'll remove the WIP flag and propose similar changes to our other
cookiecutters for consistency.

[*] https://review.openstack.org/592520
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [cinder] Reminder about the weekly Cinder meeting ...

2018-08-13 Thread Jeremy Stanley
On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote:
> I know we did a ping last week in #openstack-ansible for our meeting no
> issue. I wonder if it's a length of names thing or a channel setting.
[...]

Freenode's Sigyn bot may not have been invited to
#openstack-ansible. We might want to consider kicking it from
channels while they have nick registration enforced.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

2018-08-09 Thread Jeremy Stanley
On 2018-08-09 11:41:38 +0200 (+0200), Balázs Gibizer wrote:
[...]
> There is a list of projects (we know of) consuming the legacy
> interface and we would like to know if any of these projects plan
> to switch over to the new interface in the foreseeable future so
> we can make a well informed decision about the deprecation.
> 
> 
> * Searchlight [3] - it is in maintenance mode so I guess the answer is no
[...]

With https://review.openstack.org/588644 looking likely to merge and
Searchlight already not slated for inclusion in Rocky, I recommend
not basing your decision on what it is or isn't using at this point.
If someone wants to resurrect it, updating things like the use of
the Nova notification interface seem like the bare minimum amount of
work they should commit to doing anyway.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [cyborg]Team Weekly Meeting 2018.08.08

2018-08-08 Thread Jeremy Stanley
On 2018-08-08 16:45:22 +0800 (+0800), Zhipeng Huang wrote:
> We are rushing towards the end of Rocky cycle and let's use the meeting to
> sync up with any important features still on the fly.
> 
> starting UTC1400 at #openstack-cyborg, as usual

Please consider adding your meeting to the IRC meetings schedule at
http://eavesdrop.openstack.org/ (the first sentence in the section
contains instructions for doing so), that way people in the
community can find out when it is held without having to rely solely
on announcements. Thanks!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] Stepping down as coordinator for the Outreachy internships

2018-08-08 Thread Jeremy Stanley
On 2018-08-07 20:47:28 (-0300), Victoria Martínez de la Cruz wrote:
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round.
[...]

You've done a great job, and mentoring a new coordinator is just
another great example of that; thanks for all you've done and all
you have yet to do, it's important!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] PTG Denver Horns

2018-08-08 Thread Jeremy Stanley
On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:
> So basically, we have added "sl" to osc. Duly noted.
> 
> (FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
> migration. The train "stutters" a bit during the cutover.)
> 
> Now I can base it on PTG design work in a backronym fashion.
[...]

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [infra][horizon][osc] ClientImpact tag automation

2018-08-02 Thread Jeremy Stanley
On 2018-08-02 14:16:10 -0500 (-0500), Sean McGinnis wrote:
[...]
> Interesting... I hadn't looked into Gerrit functionality enough to know about
> these. Looks like this is probably what you are referring to?
> 
> https://gerrit.googlesource.com/plugins/its-storyboard/

Yes, that. Khai Do (zaro) did the bulk of the work implementing it
for us but isn't around as much these days (we miss you!).

> It's been awhile since I did anything significant with Java, but that might be
> an option. Maybe a fun weekend project at least to see what it would take to
> create an its-launchpad plugin.
[...]

Careful; if you let anyone know you've touched a Gerrit plug-in the
requests for more help will never end.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [nova] How to debug no valid host failures with placement

2018-08-02 Thread Jeremy Stanley
On 2018-08-02 14:04:10 -0600 (-0600), Chris Friesen wrote:
[...]
> At a previous Summit[1] there were some operators that said they just always
> ran nova-scheduler with debug logging enabled in order to deal with this
> issue, but that it was a pain to isolate the useful logs from the not-useful
> ones.
[...]

Also, the OpenStack VMT doesn't prioritize information leaks which
are limited to debug-level logging[*], so leaving debug logging
enabled is perhaps more risky if you don't safeguard those logs.

[*] https://security.openstack.org/vmt-process.html#incident-report-taxonomy
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [infra][horizon][osc] ClientImpact tag automation

2018-08-02 Thread Jeremy Stanley
On 2018-08-02 10:09:48 -0500 (-0500), Sean McGinnis wrote:
[...]
> I was able to find part of how that is implemented in jeepyb:
> 
> http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py
[...]

As for the nuts and bolts here, the script you found is executed
from a Gerrit hook every time a change merges:

https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/change-merged

Gerrit hooks are a bit fragile but also terribly opaque (the only
way to troubleshoot a failure is a Gerrit admin pouring over a noisy
log file on the server looking for a Java backtrace). If you decide
to do something automated to open bugs/stories when changes merge, I
recommend a Zuul job. We don't currently have a pipeline definition
which generates a distinct build set for every merged change (the
post and promote pipelines do supercedent queuing rather than
independent queuing these days) but it would be easy to add one that
does.

It _could_ also be a candidate for a Gerrit ITS plug-in (there's one
for SB but not for LP as far as I know), but implementing this would
mean spending more time in Java than most of us care to experience.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [all][election] PTL nominations are now closed

2018-08-02 Thread Jeremy Stanley
On 2018-08-02 10:58:53 +0200 (+0200), Thierry Carrez wrote:
[...]
> Finally, RefStack: I feel like this should be wrapped into an
> Interoperability SIG, since that project team is not producing
> "OpenStack", but helping fostering OpenStack interoperability.
> Having separate groups (Interop WG, RefStack) sounds overkill
> anyway, and with the introduction of SIGs we have been recentering
> project teams on upstream code production.

That was one of the possibilities I discussed with them during their
meeting a month ago:

http://eavesdrop.openstack.org/irclogs/%23refstack/%23refstack.2018-07-03.log.html#t2018-07-03T17:05:43

Election official hat off and TC Refstack liaison hat on, I think if
Chris Hoge doesn't volunteer to act as PTL this cycle to oversee
shutting down the team and reassigning its deliverables, then we
need to help them fast-track that nowish and not appoint a Stein
cycle PTL.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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


  1   2   3   4   5   6   7   8   9   10   >