-installed on the executor
too ?)
Thanks for the full analysis, I learned a couple of things :)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
g on the executor -- the trick is that for
such a short job the overhead of requesting a test node is a bit heavy,
and we want to run the job on every vote change on release requests
Other ideas?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenS
as that constituency feels is appropriate.
The advisory board will also serve as a point of contact for the OpenDev
project when making changes that may be disruptive. The intent is to create
bidirectional communication between OpenDev and the advisory board.
How does this look?
Loving it.
--
Thierry
Jeremy Stanley wrote:
On 2019-12-04 09:45:48 -0500 (-0500), Mohammed Naser wrote:
On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote:
[...]
I'm also wondering if the advisory board should not also include seats
for the infrastructure donors... Since we should definitely be making
sure
or the infrastructure donors... Since we should definitely be making
sure Opendev goes in a direction that encourages them to continue
investing in (or increase) the resources that they give us.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
Jeremy Stanley wrote:
On 2019-11-14 17:14:35 + (+), Jeremy Stanley wrote:
On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote:
[...]
"checking that the PTL or designated liaisons have actually +1 the
request, before casting our own +2 vote."
[...]
Not that I hav
mpler ways to achieve a similar results.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Sorin Sbarnea wrote:
Having a StackOverflow kind Q site is of great value but only if there is
enough critical mass to maintain it. Clearly ask.openstack.org is far from reaching
that mass.
I would personally see more useful to redirect users to two existing platforms
that already passed the
Jim and Thierry wrote:
[...]
One consequence of that transition is that non-OpenStack repositories
that were previously mirrored to GitHub under the "openstack"
organization are now stale and no longer updated, which is very
misleading. Those should now be retired, with a clear pointer to the
Hi everyone,
The migration of our infrastructure to the Opendev domain gave us the
opportunity to no longer have everything under "openstack" and stop the
confusion around what is a part of OpenStack and what is just hosted on
the same infrastructure. To that effect, in April we transferred
to retrieve our deliverables (pypi, git).
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
for the repo
renames under the Infrastructure team, but we have to do that anyway.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
openstack-infra/ -> openstack/
rename, with things like:
openstack-infra/gerrit -> openstack/gerrit
Shouldn't that be directly moved to opendev/gerrit? Moving it to
openstack/ sounds like a step backward.
--
Thierry Carrez (ttx)
___
OpenStack-Infra m
, not
listed above)
AFAIK we can remove these two as well - looking at:
https://review.openstack.org/254817
Yes releasestatus is not used anymore.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http
:)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
(although Vinay Yadhav might be able to change that as the
original registrant), and the OpenStack Administrators was never added
as a co-owner.
Anil: any chance you could update the maintainer ?
Thanks in advance,
--
Thierry Carrez (ttx)
___
OpenStack
kly basis
> for other things...?
Maybe we should engage with other currently "monthly" meeting chairs and
ask them how happy they would be with a 4weekly ? Because if they don't
plan to switch to it, there is little point in pursuing that option ?
--
Thierry Carrez (ttx)
signature.a
Blair Bethwaite wrote:
> On 10 Nov 2016 8:56 PM, "Thierry Carrez" <thie...@openstack.org
> <mailto:thie...@openstack.org>> wrote:
>>
>> The issue with this solution is that any "monthly" slot ends up being
>> exactly the same as a "wee
Tony Breeds wrote:
> On Wed, Nov 09, 2016 at 10:56:38AM +0100, Thierry Carrez wrote:
>
>> Our scheduling system currently only supports biweekly or weekly
>> meetings. We don't currently support monthly or triweekly meetings
>> (mostly to avoid having to detect complex
fficult to find empty
slots manually.
Any chance you could express what you are after using only biweekly
meetings ? Like schedule odd Mondays, odd Thursdays and even Tuesdays ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Inf
Jeremy Stanley wrote:
On 2016-06-21 17:34:07 + (+), Jeremy Stanley wrote:
On 2016-06-21 18:16:49 +0200 (+0200), Thierry Carrez wrote:
It hurts a lot when it's down because of so many services being served from
it. We could also separate the published websites (status.o.o
of so many services being served
from it. We could also separate the published websites (status.o.o,
governance.o.o, security.o.o, releases.o.o...) which require limited
resources and grow slowly, from the more resource-hungry storage sites
(logs.o.o, tarballs.o.o...).
--
Thierry Carrez (ttx
Docker we need,
which is 1.10 and greater.
Hope the context is useful.
OK, as I said, liberty is pre-official so I'm fine with any solution
here. We seem to be in agreement that the proposed solution should not
be applied on stable/mitaka and l
,
but we should probably protect whatever is left (while we continue the
effort of replacing those pages by properly peer-reviewed sites).
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http
ocused sprint some time ago that
was also not about training, and was also very productive :)
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
developing and maintaining the
systems and tooling used by contributors to develop OpenStack itself.
"""
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
t want to get in touch with John Dickinson (the
Swift project team lead) and discuss that with him (if you haven't already).
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/c
you'll let me know
>> if this is insane, and in that case provide alternative suggestions!
The Task tracking session is at the same time as the talk Doug and
myself are giving on the conference side... I'd really like to be able
to attend that session though -- any chance you could move that one to
for those projects,
it's easy to create one and abandon it.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
: it will ultimately result in them
forking their future development on another platform. To avoid that, I'd
rather reboot the team completely and give them the keys.
Thoughts ?
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra
fair for infra-core to quickly revert commits that would
break our production instance. That sounds like a reasonable compromise:
let devs make fast progress but still keep our continuous deployment to
storyboard.o.o.
--
Thierry Carrez (ttx
OpenStack needs. Hope this was helpful.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
to what we need, as an extension:
https://git.wikimedia.org/tree/phabricator%2Fextensions%2Fsecurity.git
Next up on my list, looking into the CLI and API.
[1]
https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Type_of_project
--
Thierry Carrez (ttx)
diff --git a/src
...
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
is basically done
as based on a day, and a week-of-month position:
[...]
Right, there is nothing technical preventing to encode it in ICAL -- it
just generates so much conflicts that we so far preferred to not offer
the option.
--
Thierry Carrez (ttx
the release management team should own it?
Works for me. Or we can make it a TC-owned repo.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
anyway. Release reporting is quite separate from task tracking,
Launchpad just accidentally did both.
Hope this helps,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin
to allow any registered user to
approve/merge changes this seems like it would be a quick loophole
for achieving ATC.
Right, those were intentionally kept in limbo. Let's keep it tis way.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack
around, that would be great.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
OpenStackID, multi-task features with tags and comments, task
dashboards, no more silly timeouts, comprehensive API...). Unlikely, but
still possible :)
I look forward to that discussion in Vancouver on the future of task
tracking in OpenStack.
--
Thierry Carrez (ttx
some StoryBoard devs quite happy.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
to simply push the branch, if you have the required
permissions in Gerrit.
That's what the release script which creates proposed/$SERIES branch
operates:
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/rccut.sh#n77
--
Thierry Carrez (ttx
it manually ?)
Staying put,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Cross-posting from -dev
FWIW I agree with the request, the wiki session duration seems to have
been dramatically lowered a few months ago.
Message transféré
Sujet : [openstack-dev] Session length on wiki.openstack.org
Date : Fri, 5 Dec 2014 12:03:49 +1100
De : Tony Breeds
to organize his
development cycle.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
for a
proper program request to be submitted. It's not a quick and easy
discussion though: there are competing approaches, the question of
whether all client libraries should also live under that program, and
the question of whether it should be lumped in a bigger end-user UX program.
--
Thierry
.
Don't get me wrong, I don't want to prevent anyone from working on
anything they would like to. I'm just afraid that this is a large
project and I don't see it attracting enough contributors to be a
long-term sustainable alternative... potentially making it a gigantic
distraction.
--
Thierry
.
[...]
Being fully aware of the irony, I'll play the devil's advocate:
Could you detail why improving Gerrit is not an option ? At first glance
its development seemed to be open enough, and it didn't appear
fundamentally wrong (just needing a few incremental changes).
--
Thierry Carrez (ttx
the
same check/gate mechanisms we have for everything else. It sounds a lot
more difficult to set up such automated verification in the drupal case,
so that would push the conflict validation onto the human reviewing the
change...
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital
James E. Blair wrote:
Thierry Carrez thie...@openstack.org writes:
To script milestone-proposed branch creation, it looks like granting
createReference to Release managers on refs/heads/proposed/* would do
the job (although maybe the current push permission on
refs/for/refs/* might already
/jeepyb/projects.py#L134
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
it openstack FOO. This grey area serves
the marketing of a lot of companies well, but creates confusion and
dilutes whatever impression of quality and integration we may have
created on our users.
I fear that adding #openstack-BAR channels adds to that confusion.
--
Thierry Carrez (ttx
to get all the right people available for review help
later...
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
to be issued by PRIVMSG :) Then that lead me to look for the nick
statusbot was running on, which was a red herring.
Proposed doc clarification @ https://review.openstack.org/48209
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra
one for those attached to it).
As long as we depend on Launchpad (which ONLY supports Launchpad's
OpenID provider) there is no way to migrate to something else anyway...
so this is more a future plans thing.
--
Thierry Carrez (ttx)
___
OpenStack-Infra
that would
free some time from the people that already work on it.
--
Thierry Carrez (ttx)
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
rejects B (because it has a bug ?). How would you reconcile
that without manually building wildly different trees ?
Regards,
--
Thierry Carrez (ttx)
Release Manager, OpenStack
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http
57 matches
Mail list logo
