ark is to get involved with
cross-project (sometimes referred to as "horizontal") programs like
documentation, quality assurance, project infrastructure, release
cycle management, et cetera.
Also, welcome aboard!
--
Jeremy Stanley
___
OpenStack-dev
of all dependant/consuming software... branchless
tempest already alleviates some of this, but not the case of changes
in a library which will break unit/functional tests of another
project.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenSta
ange as merged to the
tip of the target branch along with any other changes that change
depends on in Gerrit.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e use of Zuul's capability
to provide a common ref representing a set of different changes
across multiple projects, since independent pipelines will only ever
have an available ZUUL_REF on a single project (the same project for
which the change is b
e direction of the project at all. This is a human
judgement call, and much more helpful than just culling changes
based on age alone.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
eck needs a
categorization mechanism so that it also won't recommend rechecking
for those sorts of scenarios (all discussion of automated rechecks
aside).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.opens
oo many headaches
from trying to jump ahead substantially on fundamental bits like
libvirt. Breaking sooner and more often means those incremental
issues are easier to identify and address, usually.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStac
ust excited to see it finally within our grasp.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Ls. We could try it out
after the current point release freeze wraps up, if there's some
consensus.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n mind which you think would need to be a single spec
applying to projects in more than one program?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ted that particular step.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
x27;tox -e py27 -r' it should clear any
existing virtualenv and create a fresh one, or you can upgrade the
pip inside it with '.tox/py27/bin/pip install -U pip' if you want.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@
x configuration specifying to
always recreate the virtualenv (essentially -r) and that its
populating it with your system-installed version or perhaps an older
cached download.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ave placeholders in them. I've uploaded
https://review.openstack.org/47565 to hopefully solve the confusion.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
7;s
keys at any opportunity. I personally will be happy to make time
between sessions and at evening events to exchange key fingerprints
and show/check passports with anyone who is interested, and hope
others will do the same.
--
Jeremy Stanley
nts and so on).
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I've done a little brainstorming in updates to
https://launchpad.net/bugs/1118469 for a phased approach to possibly
implementing some of these improvements on the infra/release
automation side of things.
--
Jeremy Stanley
___
OpenStack-dev mailing
structure documentation.
The source for the file above is maintained at:
http://git.openstack.org/cgit/openstack-infra/config/tree/doc/source/third_party.rst
>
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
openstack.org/47745 to
see what breaks (though unit tests for individual projects are not
covered by this test and may also need fixing).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
they're proposed so it's still covered during
that latter phase.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2013-10-03 06:54:10 -0700 (-0700), Gary Kotton wrote:
> I think that I may have stumbled upon the problem, but need the help from
> someone on the infra team.
[...]
I'm manually launching the test script on a fresh VM now and should
have something shortly.
--
Jer
ill read the
old data from it if it hasn't already been overwritten.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
turned empty/all-zero and don't get
allocated actual addresses on the underlying storage medium until
written.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_external_references
That said, if the work I'm doing is trivial fixup to someone else's
change and I'm not substantially contributing to the overall
idea/implementation, I don't bother to add one... only if it's a
significant departu
what we're applying is
a *copyright license*. ;)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e author and date of
each commit looking for new affiliations. That seems like it would
be hacky, fragile and inaccurate, but probably still more reliable
than expecting thousands of contributors to keep that information up
to date when submit
#x27;t really how copyright
works in most Berne Convention countries, but I also don't think
reviewers would object to any copyright holder adding a separate
commit to update valid copyright claims on a particular file which
they previously neglected to document.
--
Jeremy Stanley
___
On 2013-10-20 13:00:31 + (+), Jeremy Stanley wrote:
[...]
> automated job which proposes changes to a copyright holders list
> in each project by running a query with the author and date of
> each commit looking for new affiliations
[...]
Though the more I think about this, it
we could manually maintain it using the same
mechanisms we do for the contents of the copyright headers in other
files (resulting in at best the same end result, and at worst a new
conflicting set of data to reconcile).
--
Jeremy Stanley
___
OpenStack-dev mailing
being able to submit code reviews for
things like translations and requirements updates.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
any rate, it seems that the
agreement boils down to "copyright holders promise that they're
contributing code under this license, or that they're submitting
someone else's work who probably is okay with it."
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
key and are
open to some opportunistic signing then don't hesitate to approach
others whom you know also use theirs and inquire whether they have a
moment for you to show each other identification and exchange key
fingerprints.
I hope to see many of you at the summit--and of course feel free to
ask m
s and want to
exchange ID with someone, just let them know and see if they might
be able to work out a quick face-to-face in the hallway, at lunch or
maybe during one of the evening parties.
--
Jeremy Stanley
___
OpenStack-dev mailing list
ot more tests, I think they
got a lot of benefit from the new experience as well, and I was
appropriately humbled for my lax attitude over the situation which
nearly allowed us to miss a great opportunity at educating another
developer on the merits of test coverage.
--
Jeremy Stanley
_
nch/no
corresponding series task on the bug, missing bug supervisor
permissions on that project for the Launchpad account used by our
automation, transient API failures due to network or server issues,
et cetera). I can probably spot the specific issue with a bit more
context to go on.
--
Jeremy S
r-facing messages and documentation provides value. The more
problems you can find (and ultimately help prevent) in a change, the
faster your reputation will grow.
As has been said many times already, OpenStack does not lack
developers... it lacks reviewers.
--
Jeremy Stanley
__
On 2013-11-01 18:32:51 -0400 (-0400), Nick Chase wrote:
[...]
> (Not sure actually what the difference would be from IRC,
> actually, though.)
Or, for that matter, the chat panel built into Etherpad itself.
--
Jeremy Stanley
___
OpenStack-dev m
e conversation is moving around the room a lot.
[...]
This sounds like good feedback in favor of the current Asterisk
server approach. Perhaps we should dogfood it for remote
participation in upcoming team sprints?
--
Jeremy Stanley
___
OpenStack
ing up on things, so I'm happy to be
the lonely soul keeping the lights on in Infra if needed.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
Don't worry, I (and many others) will gladly step in front of any
barrage of stones hurled for suggesting we stick to free software
when collaborating on OpenStack.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
ckforge-hosted projects
[...]
Consider this my vote in favor:
https://review.openstack.org/56432
(though I'd love if someone would step forward to be the list admin
for it instead of me!)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-
se
releases trigger a mirror update, so hopefully this will be less
painful in the future.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
sually just contact the PTL and hope he/she is around). As
discussed at the summit, we're going to work on putting together a
more detailed prerequisites list for determining whether a given
project is under security support.
https://etherpad.openstack.
of course dangerous if you
have other uncommitted files lying around in your repo you want to
keep. Instead the -r option to tox will clear and recreate any
virtualenv it tries to use.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@list
om a more immediate testing feedback
loop.
I don't think we have a timeline for implementation there, but it's
my recollection that's the direction we resolved to take it.
--
Jeremy Stanley
___
OpenStack-dev mailing list
Open
need to abandon an existing review just to link
it to a blueprint. You only need to mention the blueprint in an
amended commit message and push an updated patchset for it. The
topic will be automatically updated by a hook on the code review
system.
my integration tests, so
that it could be played back through the dummy shell later in
automated tests.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
il address. We've run into a few
like that which needed cleaning up, usually following LP
account/OpenID changes. I'll look into it and follow up with you
privately to resolve the issue.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-d
On 2013-07-01 15:10:26 -0700 (-0700), Mark Washenberger wrote:
[...]
> The talk about permanence confuses me, unless we mean that more
> permanent values are overridden by less permanent ones.
[...]
I think the "permanence" counter argument (which I don't agree with,
just recounting it for complet
ps the list moderators can check whether
your subscribed address is bouncing deliveries back?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
push your working branch to
somewhere I could pull from so I can test it myself? Feel free to
follow up with me in private or open a bug against git-review on
Launchpad if you don't want to run through troubleshooting
back-and-forth on the list.
--
Jeremy Stanley
.openstack.org:29418/openstack/quantum.git
* [new branch] HEAD -> refs/publish/master/bp/ml2-vxlan
Hope that helps?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arefully, for things like
building dependent series from previously unrelated changes. I'm
glad I listened!
> I can simplify my backport script[1] significantly now.
>
> [1] https://gist.github.com/vishvananda/2206428
Neat! I had no idea you were doing that via git-revi
uantum. Looks like there are about 15 people /join'd
in it at the moment... are there other channels we overlooked?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is in the gate pipeline
already). Long story short, horizon and one of horizon's
non-OpenStack dependencies disagreed over which versions of
python-keystoneclient they needed in such a way that there was no
resolvable overlap.
--
Jeremy Stanley
___
OpenSta
oposed changes or reverify any
approved changes which failed with that error.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
discussion with Jan Dittberner.
[...]
At this point any of you can simply propose it as a code review
change to the stackforge/sqlalchemy-migrate project. Also, if anyone
wants to volunteer as initial members of sqlalchemy-migrate-core...
--
Jeremy Stanley
_
On 2013-07-20 10:02:34 +0800 (+0800), Gareth wrote:
[...]
> xattr can't be installed correctly.
[...]
> BTW, Swift and Glance are influenced.
One of xattr's dependencies was cached in a broken state, but should
be resolved as of the past couple hours.
--
d Fabre
> Mathieu Gagné
> Antoine Musso
All four have my vote. Each of them has provided invaluable feedback
on JJB reviews for quite a while now.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.
mailing list, should you require
assistance setting up tests for Python 3.3 compatibility in a
project.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
out from under them (at least where
the dependencies under our direct control are concerned). This also
means we'll probably have to start pinning third-party dependencies
in the future if they temporarily break py3k compatibility.
--
Jeremy Stanley
asynchronous
voting. This is actually a really neat idea!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ng any changes which
have been applied to it since migration.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t; goes down.
[...]
This might actually be a good case for making that project operate
in cherry-pick mode. For an example, look at the git notes on an
openstack-infra/config change...
https://github.com/openstack-infra/config/commit/4f8ed2c
--
Je
eserve the
voting record for TC measures.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
p
(particularly if they're not all on one line, "bug" is not one of
the first two words or there are additional words after it prior to
the bug number). Best of course is to use the new headers mentioned
there, so you can also benefi
them and encourage
contributors to manually set their bugs to fix-committed once their
changes merge rather that hassling with amending commit messages and
further delaying reviews in the process. The bug update hook in
Gerrit does not work 100% of the time, so manual intervention is
still som
On 2013-08-16 11:04:14 -0400 (-0400), Doug Hellmann wrote:
> I'd like to propose Alex Gaynor for core status on the
> requirements project.
[...]
Agreed, I for one welcome his continued assistance.
--
Jeremy Stanley
signature.asc
Description: Digita
eprint
metadata headers as well. When used they should always appear
one-per-line in the final paragraph of the commit message, but their
relative order is unimportant.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.o
a project, my recommendation is:
neither. Link them to your published documentation (and make sure it
includes information on where to browse and clone your source
code!).
--
Jeremy Stanley
__
OpenStack Development Mailing List
nsummit.sched.org/event/c4170a605301dbf9bfa19b9e6a651a87
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://li
ion printed on
business cards and always carry plenty with me when I travel for
conferences.
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
o need to install the services from source
during the job, not in advance. Otherwise you would be unable to
have your project's change declare a cross-repository dependency
(depends-on) to a pending change in another one of those projects.
--
tuations where the requirements change and
the diskimages haven't been rebuilt or in jobs testing proposed
changes which explicitly alter these requirements, but could be
augmented by similar mechanisms in devstack itself to avoid building
the
g it up to the individual projects/jobs to
define the packages they'll need to be able to run. I'll save the
lengthy list of whys, it's been in progress for a while and we're
finally close to making it a reality.
--
Jeremy Stanley
___
e else more suitable (especially without a suggestion as
to where that might be).
3. The core review team for this is the core review team for all our
infrastructure systems, and we're all unfortunately very behind in
handling the current review volume.
--
Jeremy Stanley
___
tall
Also if change 237936 gets corrected in the next 18 hours or so, we
may rename:
openstack/networking-bagpipe-l2 -> openstack/networking-bagpipe
As always, feel free to follow up to this message or pop into
#openstack-infra on Freenode if you have any questions/concerns.
--
Jeremy
m thrilled by those of you who intend to make it a reality, we can
revisit the LTS discussion once you finish that).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
t) about
Cassandra which _did_ in fact have some confirmation from their
developer community--at least in the form of code comments--of only
being reliable/supported in conjunction with a non-free JDK. Thanks
be to Joshua for setting me straight in #opens
ee an SSH banner starting
with a string like "SSH-2.0-GerritCodeReview_2.8.4-19-g4548330
(SSHD-CORE-0.9.0.201311081)" or something else?
--
Jeremy Stanley
signature.asc
Description: Digital signature
__
OpenStack
ime and starts a
list of jobs associated with that pipeline for any projects. This is
why the working periodic jobs have different names than their gerrit
triggered pipeline equivalents... they need to hard-code a branch
(usually as a JJB parameter).
--
Jeremy Stanley
signature.asc
Descripti
7;t have configuration which enforces more than one +2, it's
just custom/convention between reviewers).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.
already showed on
> https://review.openstack.org/#/settings/.
[...]
OpenStackId and Gerrit are unrelated systems. Have you tried
changing your primary E-mail address on your OpenStack Foundation
member profile at https://www.openstack.org/profile/
s improved instance turnaround for us.
There may also have been other reasons for recommending rebuild to
us, but if so I don't recall what they were.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usag
fter the 2014.2.4 release on November 19. If projects want
to restore Python 2.6 testing, they'll need some custom job to
install the desired interpreter from somewhere unofficial (e.g. the
deadsnakes PPA for Ubuntu Trusty) at runtime.
--
Jeremy Stanley
___
ven if their associated votes are not, so there is no way in the
reviewers box of the Web UI right now to distinguish someone who
commented without voting (a.k.a. a 0 vote) on the current patchset
from someone who only voted on previous patchsets.
--
Jeremy Stanley
le for half hour since. That's not to say I
have much faith at the moment it'll stick around, but it's at least
an improvement.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions
have to pick another :)
Thanks--I (perhaps incorrectly?) assumed that only those they
maintain in the chat.freenode.net DNS round-robin are considered
active.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage qu
This
is contradictory with performing upgrade testing *to* every
supported stable branch, since there will always be a starting point
we test upgrading *from* without being able to continue supporting
the version which came before it.
--
Jeremy Stanley
__
, to try "just" installing
(and running) Juno DevStack. We have enough trouble doing that in
our CI system right now.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
h
"unimportant" security advisories, as it would be a waste of all our
time and we already have plenty of other things to do. ;)
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usa
ss how we
can keep Juno on some semblance of life support (that discussion
concluded more than a year ago), it's time for discussing what we
can implement in Mitaka so we have more reasonable options for
keeping the stable/mitaka branch healthy a year from now.
--
Jeremy Stanley
signatu
hile they may have basically
identical contents, were not generated at the same time nor by the
same event so it's perfectly reasonable that the former would be
versioned as a dev commit working toward the release tag of the
latter.
--
Jeremy Stanley
__
something for once... ;)
--
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
ace).
I find it's preferable to review code without thinking about who
wrote it, though admittedly that's sometimes easier said than done.
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage ques
t
any time they see fit.
--
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/m
rrect over time, so hopefully our member companies are
figuring this dynamic out for themselves. ;)
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
rathon?
--
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
aborative effort of the Puppet OpenStack team instead (per
Emilien's original suggestion).
--
Jeremy Stanley
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
nk to locally installed distro
packages of fonts and similar resources might get complicated, and
so may still be easier left as distro-specific patches in their
respective packaging).
--
Jeremy Stanley
__
OpenStack Developmen
301 - 400 of 1706 matches
Mail list logo
